View BT740-SC_9104769.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

enhanced class 1 bluetooth v2.1 module f irmware u ser s g uide v ersion 1. 3 part # bt740 - sa, bt74 0 - sc am ericas: +1 - 800 - 492 - 2320 option 2 europe: +44 - 1628 - 858 - 940 hong kong: +852 - 2923 - 0610 www.lairdtech.com/bluetooth
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 2 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 r evision h istory revision revision date description 1.0 24 june 13 first release 1.1 16 july 13 minor changes to gpio 1.2 25 august 14 addition of appendices for at commands, s registers, and error codes. 1.3 19 june 15 updated command examples
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 3 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 t able of c ontents revision history ................................ ................................ ................................ ................................ ............... 2 table of contents ................................ ................................ ................................ ................................ ........... 3 1 at command set ................................ ................................ ................................ ................................ ..... 4 2 s registers ................................ ................................ ................................ ................................ .............. 24 3 multipoint protocol ................................ ................................ ................................ ................................ 39 4 module events ................................ ................................ ................................ ................................ ........ 95 5 hdp profil e related events ................................ ................................ ................................ .................... 102 6 debug events ................................ ................................ ................................ ................................ ....... 103 7 data channels ................................ ................................ ................................ ................................ ...... 105 8 multipoint application examples ................................ ................................ ................................ .......... 109 9 at application examples ................................ ................................ ................................ ...................... 124 10 appendices ................................ ................................ ................................ ................................ .......... 149 10.1 at commands ................................ ................................ ................................ ............................ 149 10.2 s registers ................................ ................................ ................................ ................................ .. 150 10.3 error responses ................................ ................................ ................................ .......................... 153
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 4 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 1 at c ommand s et 1.1 introduction to at commands this chapter describes the at protocol used to control and configure the bt740 - sx bluetooth module s after it is configured to present an at protocol instead of the alternate multipoint packet - based interface. the multipoint protocol is also described in this document. the protocol is similar to the industry standard hayes at protocol used in telephony modems, as both types of devices ar e connection oriented. the extended at command set make s the laird device performs the three core actions of a bluetooth device: establis h bluetooth connections, pair, and inquire . many other provided at commands perform ancillary functions, such as truste d device database management and s register maintenance. just like telephony modems, the laird device powers up in an unconnected state and only respond s via the serial interface. in this state the laird device can respond to bluetooth inquiries. then, jus t like c ontrolling a modem, the host issue s at commands which map to various bluetooth activities. these at commands have appropriate counterparts in the alternate multipoint packet based protocol which also achieve the same goal. the nature of at protoc ol allows it to control and manag e only one connection at a time; this is in contrast to the multipoint packet protocol which can simultaneously control many connections. the main advantage at protocol offers is simplicity. th e module has a serial interf ace through which the at protocol is channeled , which can be configured for ba ud rates from 1200 up to 921600 and has an rf communications end point. the default baud rate for at command mode modules is 9600 bps. the rf communications endpoint has a conc ept of connected and unconnected modes and the at protocol at the serial interface has a concept of command and data modes. this leads to the matrix of states shown below. rf unconnected rf connected command mode allowed allowed data mode illegal allowed the combination data + rf unconnected mode does not make sense and is ignored. navigation between these states uses the at command/responses , described in detail in subsequent sections. there are many references to the term s register in the r est of this document. these are an array of integer values stored in non - volatile memory which are used to configure the module so that it behaves in a certain way afte r powering . these s register s have two attributes; a value and an id. the id is a p ositive integer number used in appropriate com mands to read/write the values. 1.2 at protocol mode 1.2.1 at protocol assumptions the csr (cambridge silicon radio) bluetooth chipset in laird devices has limited memory resource s . therefore it is not proposed that the re be full implementation of the at p rotocol as seen in modems. the claim made for this device is that it has a protocol similar to an at modem. in fact, the protocol is similar
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 5 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 enough so that existing source code written for modems can be used with very l ittle modification with a laird device. therefore the following assumptions are made: ? all commands terminate by the carriage return character 0x0d, represented b y the string in subsequent sections . it cannot be changed at runtime. ? all responses from the laird device have carriage return and linefeed characters preceding and appending the response. these dual character sequences have the values 0x0d and 0x0a respectively and are represented by the string . ? all bluetooth addres ses are represented by a fixed 12 digit case insensitive hexadecimal string. ? all bluetooth device class codes are represented by a fixed 6 digit case insensitive hexadecimal string. ? most new bluetooth specific commands are identified by the string +btx, wh ere x is generally a mnemonic of the intended functionality. 1.2.2 protocol activation depending on the variant of the module, the at protocol need s to activate so that on power up it presents this protocol interface instead of the al ternate multipoint protocol. the method that is always available and work s is activation via s register 255 in multipoint mode (and mapped to 9255 in at mode), where setting a value of 1 selects multipoint packet protocol and a value of 2 selects at proto col. note : changes to this s register store in non - volatile memory at time of change and does not require the at&w command (or the equivalent in multipoint mode cmd_store_reg) to commit to non - volatile memory. optionally , some firmware variants allow a val ue of 0 in this s register and in this case on power up the protocol selection depends on the state of one of the gpio pins (user settable) so that one state forces at and the other forces multipoint. 1.3 a t commands and responses this section describes all available at commands. many commands require mandatory parameters and some take optional parameters. these parameters are integer values, strings, bluetooth addresses or device classes. the following convention is used when describing the various at commands , and the re sponse to a command is also stated. a 12 character bluetooth address consisting of ascii characters 0 to 9, a to f and a to f. of ascii characters 0 to 9, a to f and a to f. preceded by the $ character. a 4 character uuid number consisting of ascii characters 0 to 9, a to f and a to f.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 6 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 1.3.1 enter local command mode command: ^^^ response: ok description: when in data and connected mode, the host can force the device into a command and connected mode so that at c ommands can be issued to the device. the character in this escape sequence is specified in the s2 register, therefore it can be changed. in addition, the escape sequence guard time is specified by s register 12. by default the guard time is set to 100 mill iseconds . please refer to the dropping connections section for more related information. in modems this escape sequence is typically {delay} + {delay} + {delay} + {delay}, and configures by default to avoid confusion wh en the module is providing access to a modem. 1.3.2 command mode status check command: at response: ok description: ok 1.3.3 accept incoming connection (answer call) command: ata response: connect 123456789012,,< where is the profile with the established connection. d escription: accept an incoming connection, which is indic ated by the unsolicited string ring 123456789012 , where 123456789012 is the bluetooth address of the connecting device. 1.3.4 make outgoing connection command: atd, response: connect 123456789012,,> or no carrier description: make a connection to device with bluetooth address and profile . the is an optional parameter which specifies the uuid of the profile server to attach to, and if not supplied then uses the def ault uuid for spp (1101) . the uuids in the following table are allowed: profile name uuid serial port 1101 hid 1124 hdp use appropriate canned hdp commands in s tead
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 7 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 1.3.5 enable/disable echo command: aten response: ok or error nn description: this command enables or disables the echo of characters to the host . the default echo condition set s via s register 506. this command does not affect the s register 506. 0 disable echo. 1 enable echo. all other values of n generate an error. 1.3.6 drop connection command: ath response: < cr,lf>no carrier or ok description: drop an existing connection or reject an incoming connection indicated by the unsolicited ring message. if a connection does not exist then the response is ok. 1.3.7 information command: atin response: for recognized values of n. as appropriate ok all other values of n generate laird technologies inc (c)2010 ok description: this return s the information in the following table about the laird device. the list is not exhaustive as there are some values of n which generate information for use by laird support. table 1 - 1 : laird device information index description 0 the product name/variant. 1 the underlying ccl stack version information. 3 the laird firmware revision format a.b.c.f.g (see 333 for further details) 333 the full laird firmware revision format a.b.c.d.e.f.g , where a = hardware platform b = major stack version number (changes when ccl stack changes : see ati1) c = major app version number (changes when number of profiles change) d = developer id
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 8 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 index description e = branch id f = build number ( divisible by 10 for production releases and odd for engineering) g = twig number (will normally be 0, but minor releases on sub - branches is non - zero) 4 a 12 digit hexadecimal number corresponding to the bluetooth address of the laird device. 6 the maximum size of trusted device database. 9 0 if not in a connect state and 1 if in a connect state. 11 the re ason why a no carrier results in the most recent attempt at making an outgoing connection. where the response values are as follows: 3 = normal disconnection 13 current sniff parameters in two lines as follows a,b,c,d a,b,c,d where first line is in units of milliseconds and the second in baseband slots. a = attempt (see s reg 73, 561 in at mode) b = timeout (see s reg 74, 562 in at mode)) c = minimum interval (see s reg 75, 563 in at mode) d = maximum interval (see s reg 76, 564 in at mode) 21 current discoverable mode: 0 = not discoverable 1 = generic discoverable mode 2 = limited discoverable mode 22 current connectable mode: 0 = not connectable 1 = connectable 23 same as (9) above. 0 if not in a connect state and 1 if in a connect state. 42 current state of the module 14 = not discoverable and not connectable and not in connection 18 = connected mode 174 = connectable and discoverable 173 = connectable only 172 = discover able only 56 the number of devices in the trusted device database in format a,b where a is the number of devices in the rolling database and b in the persistant database. 100 returns the hardware id (100 for btm4xx platform) 201 uart receive buf fer and hardware handsha king information in the format: a,b,c where a = uart receive buffer size b = threshold at which the rts output line deasserts c = threhsold at which the rts output line re - asserts again.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 9 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 index description 202 the number of times the uart_dsr input line has been detected to toggle since the module was powered or reset via appropriate commands in at and mp mode. 224 - 239 memory diagnostics information in the format a,b where a is the size of pmalloc block and b is the number that are free. low b values imply trhe module is operating at the limits of its heap resource. 1.3.8 enter data mode when connected and in command mode command: ato response: connect o r error nn description: return to data mode. assume that the module is in data mode after it receives an ok . responds with an error if there is no bluetooth connection. 1.3.9 set s register command: atsn=m response: ok or error nn description: as with modems, the lair d bluetooth module employs a concept of registers used to store parameters, such as escape sequence character, inquiry delay time , etc. the value p art m can be enter ed as decimal or hexadecimal. a hexadecimal value is specified via a $ leading characte r. for example , $1234 is a hexadecimal number. when s register values change , the changes are not normally stored in non - volatile memory until the at&w command is used . note that at&w d oes not affect some s registers; for example 520 to 525 , or 9240 to 925 5 , as they are updated in non - vol atile memory when the command processes . 1.3.10 read s register value in decimal or hex command: atsn?<$> response: for recognised values of n: as appropriate ok for unrecognised values of n: error nn description: this return s the current value of register n. if the optional $ character supplies after the ?, then the returned value is hexadecimal with a leading $. for example , the value 1000 returns as $3e8 . 1.3.11 read s registers command: atsn=? response: for recognised values of n: nnnn..mmmm ok for unrecognised values of n:
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 10 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 error nn description: this return s the valid range of values for register n. 1.3.12 send data to peer when in command mode command: atx response: ok or if a connection does not exist error 56 description: this command sends data to the remote device when in local command and connected mode. if a non - printable ascii character needs sen ding then insert the escape sequence \ hh where hh are two hexadecimal digits. the three character sequence \ hh converts into a single byte before transmission to the peer. note: for hid connections, the entire is deemed to be a single hid report. 1.3.13 factory default (full) command: at&f* response: ok or error nn description: this command erases all user parameters in non - volatile memory. the new settings become active after a reset. 1.3.14 factory default (preserve uart settings) command: at&f+ response: ok or error nn description: this command erases all user parameters in non - volatile memory except s registers 520 to 525 , and 9240 to 9255. this means tha t the trusted device database clears, but at protocol mode is retain ed and uart config (baudrate, stopbits etc) is preserved. the new protocol and settings become active after a reset.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 11 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 1.3.15 factory default (preserve protocol setting) command: at&f*at* response: ok or error nn description: this command erases all user parameters in non - volatile memory except s register 9255. this means that the trusted device database clears , but at protocol mod e retains and uart parameters reset to factory default settings. the new protocol and settings become active after a reset. 1.3.16 factory default (full, then change into mp mode) command: at&f*mp* response: ok or error nn description: this command erases all user parameters in non - volatile memory including s register 9255 and s reg 9255 is set to 1 for mp mode. this means that the trusted device database clears, and protocol set s to mp mode and all uart parameters are reset to factory default settings. the new protocol and settings become active after a reset. 1.3.17 write s registers to non - vo latile memory command: at&w response: ok or error nn description: writes current s register values to non - v olatile memory so that they retain over a power cycle. 1.3.18 write to blob(0) command: at+btb= response: ok or error nn description: this command clear s blob (0) first and then appended to that blob after the string de - escapes . this allows binary data to load into the blob buffer for subsequent proce ssing using the at+btbnnnn command syntax.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 12 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 1.3.19 append to blob(0) command: at+btb+ response: ok or error nn description: this command append s blob (0) after the string de - escapes . this allows binary data to load into the blob buffer for subsequent processing using the at+btbnnnn command syntax. 1.3.20 action and process data in blob(0) command: at+btbnnnn response: ok or error nn descripti on: this command process es blob (0) as per the action specified by nnnn. the actions are described briefly as per the table below (more details in the mp protocol section): index action 0 clear blob(0) 1 get byte count in blob(0) 2 destructively read blob(0). data sends so that non - printable data bytes are escaped with \ hh. 3 save blob(0) as hid descriptor(0) in non - volatile memory 4 load blob(0) as hid descriptor(0) from non - volatile memory 5 save blob(0) as hid service name in non - volatile memory 6 load blob(0) as hid service name from non - volatile memory 7 commit blob(0) as enhanced inquiry data 8 save blob(0) as enhanced inquiry data in non - volatile memory, to be used automatically after subsequent resets 9 load blob(0) from the enhanced inquiry data from non - volatile memory. 1.3.21 remove trusted device command: at+btd response: ok or error nn description: this command remove s the specified device from the list of trusted devices in the non - volatile database. if the device is not in the database then the response is still an ok. error response is for when the address is not a 12 character hex string. 1.3.22 remove all trusted devices command: at+btd* response: ok or error nn
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 13 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 description: this command remove s all devices from the list of trusted devices in the non - volatile database. the device does not ask for confirmation. warning : if you make a connection, the link key caches in the underlying stack. so if you subsequently delete the key using at+btd* and immediately request an authenticated connection to the same device, then the connection may be established. to ensure this does not happen, send atz after the at+btd*. 1.3.23 get the remote friendly name command: at+btf response: friendly name ok or error nn description: this command gets the remote friendly name of the specific address. if the friendly name has non printable characters (including the character ) then those characters escape into a 3 character \ hh sequence. 1.3.24 enable connectable mode command: at+btg response: ok or er ror nn description: enable page scanning only and wait s for a connection from any device. inquiry scans are disabled. the page sca n window and interval timing derive s from s reg 9009 and 9010. use ati21 and ati22 to determine the discoverable and connectable modes at any time. 1.3.25 inquire command: at+bti response: 12346789012 12345678914 ok description: this make s the device perform an inquiry for duration milliseconds and max number of unique responses, where s register 517 specifies duration and s register 518 specifies max . only the bluetooth address of responding devices is listed. 1.3.26 inquire and display devclass too command: at+btiv response: 12346789012,123456 12345678914,123456 ok description: as per at+bti but the response includes the device class code for all inquiry responses.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 14 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 1.3.27 inquire a nd get friendly names too command: at+btin response: 1234 6789012,123456,"laird bt module" 12345678914,123456, nokia n70" ok description: as per at+bti but the response includes the device class code and friendly name for all inquiry responses. the friendly name strings are in utf - 8 format as per the bluetooth specification. 1.3.28 inquire w ith enhanced inq resp command: at+btie response: 12346789012,123456,, - 45," \ 0a \ 08laird fef" 12345678914,123456,", - 75, ok description: as per at+bti but the resp onse includes the device class code, rssi, and the enhanced inquiry information. the friendly name is not acquired, as it is a time - expensive procedure and therefore an empty string sends as a placeholder. 1.3.29 set pincode o r passcode command: at+btk= response: ok or error nn description: this command provide s a passkey when pin? 12345678 or p asskey? 12345678 indications are receive d asynchronously. the string length must be in the range 1 to 16, f or pin? otherwise an error returns . the string length must be exactly 6 characters, for passkey? otherwise an error returns and each character must be a decimal digit in the range 0 to 9. if there is no ongoing pairing in progress, then the stores in non - volatile memory and may be used in subsequent legacy pairing attempts. to delete the pincode stored in non - volatile memory, submit the command with an empty string. a stored value is not used for a passkey? event. 1.3.30 reject yes/no simple secure pairi ng command: at+btkn response: ok or error nn description: when the module configures for display with yes/no security via s register 9006 , this command convey s a no for the simple pairing procedure. this command is sen t as a result of receiving a passkey? 2 asynchronous response. 1.3.31 accept yes/no simple secure pairing command: at+btky
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 15 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 response: ok or error nn description: when the module configures for display with yes/no security via s register 9006 then this command convey s a yes for the simple pairing procedure. this command is s ent as a result of receiving a passkey? 2 asynchronous re sponse. 1.3.32 set friendly name i n non - vol memory command: at+btn= response: ok or error nn description: this sets the default friendly name of this device as s een by other devices. it is s tored in non - volatile memory. use at+btn? to read it back. an empty string () delete s the string from non - volatile memory which force s the use of the default friendly name . 1.3.33 read friendly name from non - vol memory command: at+btn? response: < cr,lf>my friendlyname ok or error nn description: read the friendly name from non - volatile memory. 1.3.34 enable connectable+discoverable mode command: at+btp response: ok or error nn description: enable page and inquiry scanning and wait for a connection from any device. the page sca n window and interval timing derives from s reg 9009 and 9010 . the inquiry sc an window and interval timing derives from s reg 9007 and 9008 . 1.3.35 enable di scoverable mode only command: at+btq response: ok or error nn description: set discoverable mode only by enabling inquiry scanning. the inquiry sca n window and interval timing derives from s reg 9007 and 9008 . use ati21 and ati22 to determine the discoverable and connectable modes at any time .
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 16 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 1.3.36 set outgoing peer address command: at+btr response: ok description: this command stores a peer address for outbound connections in non - volatile memory. a value of 000000000000 has the special meaning of invalid peer address. this command is used to set up a module in pure cable replacement mode. if s register 512 = 1 and the peer address is not 000000000000, then it wi ll periodically (time specified via s register 505) attempt to connect to the peer address specified. in this circumstance all commands from the host are buffered in the receive buffer, until a bluetooth connection is established with the peer device and i t then sends the buffer across. this means if the peer device is not nearby and will never be there, the device effectively becomes useless, as in this circumstance a host would want to get attention of the at parser to send it new commands C probably one to delete the peer device. in this circumstance, a recovery is possible by one of two methods. the first method assumes that the dtr from the host is connected to the dsr line of the module and the second method assumes that this connection is absent. in the first method it is enough to deassert the dtr line from the host and that will abort the autoconnect cycle. the second method is initiated by resetting the device and then ensuring that the text string at+bt&bism& is sent (where is the carri age return character). there is special code which looks out for this magic command and terminates the autoconnect cycle if it sees it and confirms to the host of that fact by sending an ok response. 1.3.37 delete outgoing peer address command: at+btr response: ok description: this command is used to display the peer address stored in non - volatile memory, used to put the ezurio device in pure cable replacement mode. 1.3.38 read outgoing peer address command: at+btr? response: 12346789012 ok description: this command deletes the peer address previously stored using at+btr. 1.3.39 list trusted device command: at+btt? response: 12346789012 < cr,lf>12345678913 12345678914 ok or error nn description: this command list s the contents of both the rolling and the persist trusted device database. the link key does not display so the response is as shown above. if the list is
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 17 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 empty , only the ok response sends; otherwise an ok terminate s the list. use the command ati6 to read the maximum size of the trusted device database. note: all new successful pairings automatically store i n the rolling database. if the database is full, then the oldest is deleted to make room for the new one. to ensure a link key is nev er deleted, transfer it to the persist database using the command at+btt described in detail later. 1.3.40 list trus ted device command: at+bttn? response: 12346789012 12345678913 12345678914 ok or error nn description: this command list s the contents of either the rolling or the per sist trusted device database, w here n=0 for the rolling database and 1 for the p ersist database. the link key does not display so the response is as shown below. if the list is e mpty then just the ok response is sen t ; otherwise an ok terminate s the list. use the comman d ati6 to read the maximum size of the trusted device database. 1.3.41 transfer device to persist list command: at+btt response: ok or error nn description: when a successful pair ing occurs, the new link key automatically stores in the rolling database where if the database is full, the oldest device is deleted. this poses a risk of a trusted device automatically deleting, especially when the module is in just works simple pairing mode and so pairings can occur without the host being involved and so there is a definite risk of link key deletion. this command transfer s a device specified via the address supplied to the persist database so that a trusted device is never deleted automatically. 1.3.42 initiate a pairing command: at+btw response: ok or error nn description: this initiates pairing with a device whose bluetooth address is < bd_addr>. an ok response is s ent immediately and whe n the pin or passcode is required. a synchronous indications are s ent to the host in the form pin? or passkey? or pair ? where the address confirms the device with which the pairing is to be performed. to supply a pin or passco de, use the at+btk command. t o respond with a
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 18 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 yes or no, use the command at+btky or at+btkn respectively. for a suc cessful pairing, the link key automaticall y stores in the rolling database which can be queried using the at+btt0? command. note: the ok response is s ent immediately on receipt of the at+btw command. on pairing completion, an unsolicited message is s ent to the host in the form pair n , where n is 0 for a successful pairing. 1.3.43 disable connectable and discoverable mode command: at+btx response: ok or error nn description: disable page/inquiry scanning. this means it does not accept incoming connections or inquiry requests. more specifically it negates the effect of at+btq, at+btg and at+btp commands. use ati21 and ati22 to determine the discoverable and connectable modes at any time . 1.3.44 hdp: associate the agent with manager command: at+haahhhh response: ok or error nn description: this is a health device profile (hdp agent related command. refer to application examples for details). please note error 59 implies that the profile has not been activated which means bit 2 in s reg 9003 is not set and s reg 9070 is not 0. hhhh is obtained as a response to the at+hab command . 1.3.45 hdp: bind manager to agent command: at+hab,iiii response: hhhh ok or error nn description: this is a health device profile (hdp agent relat ed command. refer to application examples for det ails). please note error 59 implies that the profile has not been activated which means bit 2 in s reg 9003 is not set and s reg 9070 is not 0. iiii is the nominal code for the data specialization. 1.3.46 hdp: disassociate the agent from manager command: at+ha dhhhh response: ok or error nn description: this is a health device profile (hdp agent relat ed command. refer to application examples for details). please note error 59 implies that the profile has not been activated which means bit 2 in s reg 9003 is not set and s reg 9070 is not 0.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 19 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 1.3.47 hdp: endpoint definition in sdp record command: at+hae,iiii,endpointname response: ok or error nn description: this is a health device profile (hdp agent related command. refer to application examples for details). please note error 59 implies that the profile has not been activated which means bit 2 in s reg 9003 is not set and s reg 9070 is not 0. it insert s details in the sdp record. 1.3.48 hdp: read attribute value in agent command: at+haghhhh,aaaa,ssss response: ok or error nn description: this is a health device profile (hdp agent related command. refer to application examples for detai ls). please note error 59 implies that the pro file has not been activated which means bit 2 in s reg 9003 is not set and s reg 9070 is not 0. 1.3.49 hdp: activate sdp record for agent command: at+hal response: ok or error nn description: this is a health device profile (hdp agent related command. refer to application examples for details). please note error 59 implies that the profile has not been activated which means bit 2 in s reg 9003 is not set and s reg 9070 is not 0. 1.3.50 hdp: trigger agent scan report command: at+harhhhh,pppp[,aaaa[,aaaa[]]] response: ok or error nn description: this is a health device profile (hdp agent r elated command. refer to application examples for details). please note error 59 implies that the profile has not been activated which means bit 2 in s reg 9003 is not set and s reg 9070 is not 0. 1.3.51 hdp: write attribute value to agent command: at+hashhhh,aaaa,ssss,ddddd response: ok or error nn description: this is a health device profile (hdp agent related command. refer to application examples for details). please note error 59 implies that the profile has not been activated
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 20 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 which means bit 2 in s reg 9003 is not set and s reg 9070 is not 0. 1.3.52 hdp: endpoint definition in sdp record (manager) command: at+hme,iiii,endpointname response: ok or error nn description: this is a health device profile (hdp manager related command. refer to application examples fo r details. please note error 59 implies that the profile has not been activated which means bit 2 in s reg 9003 is not set and s reg 9070 is not 1. 1.3.53 hdp: endpoint definition in sdp record (manager) command: at+hme,iiii,endpointname response: ok or error nn description: this is a health device profile (hd p manager related command. refer to application examples for details). please note error 59 implies that the profile has not been activated which means bit 2 in s reg 9003 is not set and s reg 9070 is not 1. 1.3.54 hdp: activate sdp record for agent (manager) command: at+hml response: ok or error nn description: this is a health device profile (hdp manager related command. refer to application examples for details). please note error 59 implies that the profile has not been activated which means bit 2 in s reg 9003 is not set and s reg 9070 is not 1. 1.3.55 hdp: read attribute value (manager) command: at+hmghhhh,oooo,aaaa response: ok or error nn description: this is a health device profile (hdp manager related command. refer to application examples for details). please note error 59 implies that the profile has not been activated which means bit 2 in s reg 9003 is not set and s reg 9070 is not 1. 1.3.56 hdp: send time t o agent (manager) command: at+hmthhhh,ttttttt response: ok or error nn< cr,lf>
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 21 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 description: this is a health device profile (hdp manager related command. refer to application examples for details). please note error 59 implies that the profile has not been activated which means bit 2 in s reg 9003 is not set and s reg 9070 is not 1. 1.3.57 add to trusted device database (rolling) command: at+ky, response: ok or error nn description: this command adds (or replace s ) the and pair to the rolling trusted device data base. is a 12 hex digit b luetooth address and is a 32 hex digit random number. for more details , see the multipoint command cmd_trusted_db_add. 1.3.58 read the link key for addres s specified command: at+ky? response: ok or error nn nn is 49 if the device is not in the trusted device database nn is 45 is s reg 47 is not set to 1 description: this command read s the link key from the trusted device database for device with address . the link key information is s ent only if s reg 47 ( 9047) is set to 1. this command is gated through s reg 47 (9047) to get confirmation from t he user that they acknowledge that security is compromised by allowing link keys to be read. 1.3.59 unsolicited/ async responses the at protocol is a command/response type of protocol. this m eans that the laird device normal ly only respond s to at commands and in addition only respond s to one at command at a time. under special circumstances, unsolicited responses are s ent to the host. they are described in the following subsectio ns. each unsolicited response is prefixed and postfixed by a cr,lf two character sequence. command: no command . this is a status message. response: ring description: this string is s ent to the host every second rep eatedly when a remote device initiates a serial port connection. the fully qualified string is in the form r ing 012345678901, where 012345678901 is a 12 digit hexadecimal number which corresponds to the remote devices bluetooth address.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 22 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 command: no command . this is a status message. response: pin ? description: this response is s ent to the host during a legacy pairing negotiation (pre bt version 2.1 complia nt devices). the fully qualified string is pin? 01 2345678901, where 012345678901 is the bluetooth address of the peer device. in response, the host must supply a pin code using the at+btk command. command: no command. this is a status message. response: passkey ? n [,passcode] description: this response is s ent to the host during a simple secure pairing (ssp) negotiation and when the module is configured appropriately via s register 9006. where n is 1 for the host to display the passkey supplie d, 2 for the host to respond with either the command at+btky or at+btkn and 3 for the host to respond with at+btk=nnnnnn. the fully qualified string is : ? passkey? 1 012345678901,123456 where 012345678901 is the bluetooth address of the peer device and 12 3456 is the passcode to display to the user. ? passkey? 2 012345678901,123456 where 012345678901 is the bluetooth address of the peer device and 123456 is the passcode to display to the user. ? passkey? 3 012345678901 where 012345678901 is the bluetooth address of the peer device and the user echo es the passcode displayed on the peer device, or agree with the other user to enter the same random 6 digit passcode at both ends. command: no command . this is a status message. response: pair n description: this response is s ent to the host on completion (success or otherwise) of a pairing process. if pairing succeeds then n = 0; if a timeout occurs then n=1 ; and for all other unsuccessful outcomes the value is 2. the parameter is t he address of the peer device if available. command: no command . this is a status message. response: rx description: this response is s ent to the host when the unit is in online - command mode , s register 531 is set to 3 , and data arrives from a peer. for profiles other than spp (1101) , use s register 531 as a flag. if it is 0, then the profile is serviced in canned mode and in that case rx responses are n ot sent and neither does the atx command n eed to send d ata. if the data from the string contains non - printable characters (for example ascii 0 to 31 and ascii 128 to 255), then those characters translate into a 3 character escape sequence starting with \ . for example , the embedded sequence sends as the 6 character string \ 0d \ 0a. if the data contains the character " then it sends as \ 22. if the data contains the character \ then it sends as \ 5c command: no command . this is a status message. response: hda:associated hhhh,iiii,cccc,sssssss descri ption: this is a health device profile (hdp agent) related asynchronous response. refer to application examples for details. command: no command . this is a status message. response: hda:disassociated hhhh
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 23 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 description: this is a health device profile (hdp agent) relate d asynchronous response. refer to application examples for details. command: no command . this is a status message. response: hda:time hhhh,ttttttt description: this is a health device profile (hdp agent) related asynchronous response. refer to application examples for details. command: no command . this is a status message. response: hdm:associated hhhh,iiii,cccc,sssssss description: this is a health device profile (hdp manager) related asynchronous response. refer to application examples for details. command: no command . this is a status message. respon se: hdm:disassociated hhhh description: this is a health device profile (hdp manager) related asynchronous response. refer to application examples for details. command: no command. this is a status message. response: hdm:associated hhhh,iiii,cccc,sssssss description: this is a health device profile (hdp agent) related asynchronous response. refer to application examples for details. command: no command. this is a status message. response: hdm:scanreport hhhh:pppp .. description: this is a health device profile (hdp agent) related asynchronous response. refer to application examples for details.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 24 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 2 s r egisters all s registers are accessible when operating in at protocol mode, but in mp protocol mode the only visible s registers are listed as standard and special. standard and at s registers share the same numbers in some cases. for this reason, the sta nd ard and special registers are access ed from at mode by offsetting 9000. for example, the sta ndard s register 3 for profiles is read by using the command ats9003? and set using ats9003=n. 2.1 standard s registers this section details all the standard configuration s registers. min imum and max imum values are given in decimal, unless the value is prefixed by 0x, in that case the value is in hexadecimal. table 2 - 1 : stan dard configuration s registers regno dec (hex) min max category description 3 (03) 0 3 profiles server profile record mask bit 0 = spp bit 1 = hid bit 2 = hdp if hid is enable d , see s reg 39 for further configuration options in terms of device or host implementation. if hdp is enable d , see s reg 70 for further configuration options in terms of agent or manager services. note: d epending on the firmware build, some profiles are not available; in that case setting or clearing the appropriate bit in this register has no effect as that bit is ignored. 4 (04) 0 1 gap default connectable mode on power up/reset 0: disable 1: enable 5 (05) 0 2 gap default discoverable mode on power up/reset 0 : disable 1 : enable general discoverable mode (uses giac = 0x9e8b33) 2 : enable limited discoverable mode (used liac = 0x9e8b00)) 6 (06) 12 15 gap security io capability default security mode on power up/reset 12 = ssp + io_cap_no_input_no_output 13 = ssp + io_cap_display_yes_no 14 = ssp + io_cap_keyboard_only 15 = ssp + io_cap_display_only 7 (07) 12 2560 gap inquiry scan interval in units of msec 8 (08) 12 2560 gap inquiry scan window in units of msec
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 25 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 regno dec (hex) min max category description 9 (09) 12 2560 gap page scan interval in units of msec 10 (0a) 12 2560 gap page scan window in units of msec 11 (0b) 23 4096 spp rfcomm frame size for all rfcomm based profiles. 23 - 512 range has a granularity of 1 ; 512 to 4096 range has a granularity of 4. for example: setting 4095 set s a value of 4092 (round down new values) . note: testing and ca lcul ations by our stack vendor show that the incremental benefit above 990 is not worth the downside of handling larger payloads. 12 (0c) 1 30 general / gap link supervision timeout in seconds. this value only reads on power up when the profiles are registe rs. a fter changing the value it needs c ommitting to non - volatile memory using at&w or cmd_sreg_store and then the module needs a power cycle. 14 (0e) 0 1 ssp au to accept channel setup. if this is 1, incoming connections automatically accept. if this is 1, evt_connection_setup events are not sent to the host when an incoming connection arrives. 32 (20) 0 4 spp master/slave role preference for spp incoming connections. 0 = dont care 1 = prefer master 2 = prefer slave 3 = must be master 4 = must be slave 33 (21) 0 4 spp master/slave role preference for spp outgoing connections. 0 = dont care 1 = prefer master 2 = prefer slave 3 = must be master 4 = must be slave 34 (22) 0 7 spp if profiles reg 3 bit 0 is set and this is not 0 , then incoming spp connections are allowed up to the number specified in this register. 35 (23) 0 7 spp if profiles reg 3 bit 0 is set and this is not 0 , then outgoing spp connections are allowed up to the number specified in this register 36 (24) 0 1 profiles enable deviceid sdp record, a nd use the vid/pid as per registers 37 and 38 . 37 (25) 0 0xffff profiles usb vendor id to use in the deviceid record
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 26 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 regno dec (hex) min max category description 38 (26) 0 0xffff profiles usb p roduct id to use in the deviceid record 39 (27) - 2 2 hid s igni ficant if the hid p rofile enables via register 3. negative values imply tha t hid host profile is registered . value 0 and above imply hid device profile is registered and 0 = standard keyboard device (104 keys) . a ll other positive values are associated with custom hid device descriptors which are pre loaded using the cmd_blobmanage or at+btb command into non - volatile memory. there is mimimal validation of the hid descriptor that a user uploads. it is extremely important that a properly constructed descriptor is uploaded for storage in nonvol atile memory note: if hid functionality is not included in the firmware build, then this register is not available . 4 0 (28) 0 0x1f spp on spp connection, this specifies the initial state of the following modem control lines sent to the peer. bit 0 := rtr (rts/cts) bit 1 := rtc (dtr/dsr) bit 2 := dv (dcd) bit 3 := ic (ring indicate ri) bit 4 := fc (reserved C future use) 41 (29) 0 0xff hid hid device options: bit mask values. when the module configures as an hi d device (sreg39>=0) and sreg3 has the correct value , th en this and s reg 42 modify optional flags that are exposed in the service record that tell the host what capabilities are built into the device. the capabilities expose as bit masks. if a bit is set in this register, then the corresponding bit in sreg42 is the value used for that capability. the flag masks are : hid_sif_batterypower 0x01 h id_sif_bootdevice 0x02 hid_sif_normallyconnectable 0x04 hid_sif_reconnectinitiate 0x08 hid_sif_remotewake 0x10 hid_sif_sdpdisable 0x20 hid_sif_virtualcable 0x40 hid_sif_supervisiontimeout 0x80 for more details about what these flags do and mean, see the hid p rofile specificatio n available on the bt sig w ebsite . note: if hid functionality is not included in the firmware build, then this register is not available .
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 27 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 regno dec (hex) min max category description 42 (2a) 0 0xff hid hid device options: bit v alues. see description for sreg 41 . note: if hid functionality is not included in the firmware build, then this register is not available . 43 (2b) 0 63 hid country code exposed in hid device descriptor which have the following values: not supported arabic belgian canadian_bilingua canadian_french czech republic danish finnish french german greek hebrew hungary international_iso italian japan_ katakana korean latin american 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 netherlands_dutch norwegian persian_farsi poland portuguese russia slovakia spanish swedish swiss_french swiss_german switzerland taiwan turkish_q uk us yugoslavia turkish_f 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 note: if hid functionality is not included in the firmware build, then this register is not available . 44 (2c) 0x6 161 0x7a7 a hid language code exposed in the hid device descriptor which have the following values. each value contains ascii values of two lower case characters. for example en== 0x656e
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 28 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 regno dec (hex) min max category description note: if hid functionality is not included in the firmware build, then this register is not available. afar abkhazian afrikaans amharic arabic assamese aymara azerbaijani bashkir byelorussian bulgarian bihari bislama bengali tibetan breton catalan corsican czech welsh danish german bhutani greek english esperanto spanish estonian basque persian finnish fiji faeroese french frisian irish gaelic galician guarani gujarati hausa hindi croatian hungarian armenian zulu aa ab 'af am ar as ay az ba be bg bh bi bn bo br ca co cs cy da de dz el en eo es et eu fa fi fj fo fr fy ga gd gl gn gu ha hi hr hu 'hy' zu interlingua interlingue inupiak indonesian icelandic italian hebrew japanese yiddish javanese georgian kazakh greenlandic cambodian kannada korean kashmiri kurdish kirghiz latin lingala laothian lithuanian latvian malagasy maori macedonian malayalam mongolian moldavian marathi malay maltese burmese nauru nepali dutch norwegian occitan oromo oriya punjabi polish pashto portuguese ia ie ik in is it iw ja ji jw ka kk kl km kn ko ks ku ky la ln lo lt lv mg mi mk ml mn mo mr ms mt my na ne nl no oc om or pa pl ps pt quechua rhaeto_romance kirundi romanian russian kinyarwanda sanskrit sindhi sangro serbo_croatian singhalese slovak slovenian samoan shona somali albanian serbian siswati sesotho sudanese swedish swahili tamil tegulu tajik thai tigrinya turkmen tigrinya turkmen tagalog setswana tonga tatar twi ukrainian urdu uzbek vietnamese volapuk wolof xhosa yoruba chinese qu rm rn ro ru rw sa sd sg sh si sk sl sm sn so sq sr ss st su sv sw ta te tg th ti tk tl tn to tr ts tt tw uk ur uz vi vo wo xh yo zh
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 29 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 regno dec (hex) min max category description 45 (2d) 0 0x3ff hid primary language exposed in the hid device descriptor and the value is specified as follows ( where the values are in hexadecimal), refer to the hid specification for a complete list: neutral arabic bulgarian catalan chinese czech danish german greek english spanish finnish french hebrew hungarian icelandic italian japanese korean dutch norwegian polish portuguese romanian russian serbian croatian slovak albanian swedish thai turkish urdu indonesian ukrainian belarusian 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 18 19 1a 1a 1b 1c 1d 1e 1f 20 21 22 23 slovenian estonian latvian lithuanian farsi armenian azeri basque macedonian vietnamese afrikaans georgian faeroese hindi malay kazak swahili uzbek tatar bengali punjabi gujarati oriya tamil telugu kannada malayalam assamese marathi sanskrit konkani manipuri sindhi kashmiri nepali 24 25 26 27 29 2b 2c 2d 2f 2a 36 37 38 39 3e 3f 41 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 57 58 59 60 61 note: if hid functionality is not included in the firmware build, then this register is not available .
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 30 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 regno dec (hex) min max category description 46 (2e) 0 0x3f hid sub language exposed in the hid device descriptor and the value is specified as follows for english ( where the values are in hexadecimal); refer to the hid specification for a complete list: english_us english_uk english_australian english_canadian english_newzealand english_ireland english_southafrica english_jamaica english_caribbean english_belize english_trinidad english_zimbabwe english_philippines 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d note: if hid functionality is not included in the firmware build, then this register is not available . 47 0 1 pairing when this register is 1, in mp mode it enables the evt_link_key_ex event to be s ent to the host when the module receives the cmd_trusted_db_is_ trusted command and in at mode it enables the at+ky? command so t hat the link key information is se nt to the host in the response. by default this key is 0. by setting this to 1, the customer acknowledges that security can be compromised.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 31 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 regno dec (hex) min max category description 50..65 (32..41) 0 0 or 15 gpio this s pecifies the functionality attached to gpio 0 to 15 appropriately. 50 for gp io_0 onwards to 65 for gpio_15. depending on the platform, if the gpio does not physically exist then the max value is 0. the functio nality is specified as f ollows: 0 : none (the pio hardware is not touched) 1 : input 2 : output (0 on reset) 3 : output (1 on reset) 4 : input inverted 5 : output inverted (0 on reset) 6 : output inverted (1 on reset) 7 : uart ri input (dte) (ring indicate) 8 : uart dcd input (dte) 9 : uart dsr input 10 : uart ri output (dce) 11 : uart dcd output (dce) 12 : uart dtr output 13 : uart tx buffer not empty output 14 : input pin C select protocol 0=at,1=mp 15 : output pin C 0 f or at, 1 for mp for all uart input/ outputs (except 13 , 14 , & 15) there is an implied inversion. a logical 1 applies t o assert the outpu t , but by the time it hits the output pin or after it is read, there is automatic inversion. when writing to this location(s) , validation prevent s a write i f the new value is uart functionality and the same value already exists in another register. t he best approach to writing to this group of registers is to first write 0 to all 16 registers and then write new values to all. new values for these registers on ly come into effect after a reset/power cycle. for details of functionality 13, see section uart host power saving facility which describes how this output can be used to wake a uart host . contact the manufacturer for sp ecific mapping and functionality allocations. 70 (46) 0 1 hdp if set to 0 then an hdp a gent profile implements; o therwise with 1, a hdp manager implements . in addition, bit 2 of profiles s reg3 has to be set . note: if hdp functionality is not included in the firmware build, then this register is not available . 71 (47) 0 6500 hdp hdp agent profile related.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 32 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 regno dec (hex) min max category description 0 this is the default time i n milliseconds an hdp agent remain s in associated state while there is no activity with the hdp manger. if the value is 0, that is taken as infinite time. this time is referenced when performing a new hdp agent ieee s pecialization binding with an hdp manager bluetooth. in at mode see command at+hab , and in mp mode see cmd_hdp_bind note: if hdp functionality is not included in the firmware build, then this register is not available . 72 (48) 48 1024 hdp hdp profile related. this is the max tx pdu size and computes to the nearest multiple of 16. note: if hdp functionality is not included in the firmware build, then this register is not available. 73 (49) 0 2000 0 sniff mode / power saving sniff attempt time in units of milliseconds. 0 means disable. this value must be less than half the sniff minimum interval (sreg 75). the value stores in an 8 bit number and so a non - linear algorithm convert s between the value to the 8 bit number. this means writing and reading may yield different values. see section sniff mode explained. 74 (4a) 1 4000 0 sniff mode / power saving sniff t imeout time in units of milliseconds. 0 means disable. the value stores in an 8 bit number and so a non - linear algorithm convert s between the value to the 8 bit number. this means writing and reading may yield different values. see section sniff mode explained. 75 (4b) 1 4000 0 sniff mode / power saving sniff minimum int erval in units of milliseconds. the value stores in an 8 bit number and so a non - linear algorithm convert s between the value to the 8 bit number. this means writing and reading may yield differing values. see section sniff mode explained. 76 (4c) 1 4000 0 sniff mode / power saving sniff maximum interval in units of millisec onds. the value stores in an 8 bit number and so a non - linear algorithm convert s between the value to the 8 bit number. this means writing and reading may yield differing values. see section sniff mode explained.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 33 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 regno dec (hex) min max category description 80 (50) 100 0 7500 0 uart comms uart latency time in microseconds. in a connection, the data pump waits for x bytes (specified by sreg 11) before transferring the data to the air - side. in the event that the host sends fewer than x bytes this has the potential of those bytes never being transmitted. therefore, to cater for that scenario a timer detect s how long they sat in the buffer and if too long, send those bytes air - side anyway. how long to wait is specified by this s register. the tim er starts once when a b yte arrives in an empty buffer, not every time a byte arrives in the buffer. 81 10 80 uart comms memory usag e in percent for mp mode uart rx processing. leave to default value. o nly change on advice from manufacturer. new values round up to the nearest 10. this register controls how many memory blocks are reserved when the module receives a flood of uart data packets with small payloads. 82 2 99 uart comms the u art interface in the module uses hardware rts/cts handshaking to ensure that the low level receive buffer does not overflow. this register specifies at what fill percentage the rts output line deassert s . this value validates to ensure it is always more than re gister 83. in at mode, use the command ati201 to return a response in the format x,y,z, where x is the actual size of the uart receive buffer, y is the rts deassert threshold , and z is the rts re - assert threshold. 83 1 98 uart comms the uart interface in the module uses hardware rts/cts handshaking to ensure that the low level receive buffer does not overflow. this register specifies at what fill percentage the rts output line reasserts. this value validates to ensure it is always less than r egister 83. in at mode, use the command ati201 to return a response in the format x,y,z , where x is the actual size of the uart receive buffer, y is the rts deassert threshold , and z is the rts re - assert threshold.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 34 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 regno dec (hex) min max category description 84 0 3 uart comms configure u art latency. the default value of 0 configures the module for maximum throughput at the expense of latency. select 1 for high latency ( 25 ms polling of uart rx buffer) select 2 for medium latency (8 ms polling of uart rx buffer) select 3 for best latency (1 ms polling of uart rx buffer) selecting 3 has a severe det rimental impact on throughput. note: p olling times are correct as of this document. c ontact laird for updates. 128 (80) 0 0xfff fff gap modules class of device. if profiles sreg3 =2 (that is only hid profile) and sreg39 sets for 0 (i.e. built in keyboard hid descriptor), then this class of device is overridden with a value which specifies a hid keyboard device. note : most registers read by the firmware at reset. hence the radio requires a reset after setting a register for it to be effective. this means the relevant s register set must commit to non - volatile memory before initiat ing a reset. the s registers store to non - volatile memory using the command [cmd_store_sreg ]. 2.2 special s registers (240 to 255) registers 240 to 255 inclusive are special in the sense that when written , the value automatically commits to non - volatile memory . table 2 - 2 : special s registers regno dec (hex) min max category description 240 (f0) 0 921600 uart comms uart baudrate writing 0 implies default baudrate which may be different for all the different protocols as follows: mp mode = 115200 at mode = 9600 automatically saves to non - volatile memory on write . 241 (f1) 1 1 uart comms uart handshaking. 1=cts/rts automatically saves to non - volatile memory on write . 242 (f2) 1 2 uart comms uart stopbits automatically saves to non - volatile memory on write .
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 35 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 regno dec (hex) min max category description 243 (f3) 0 2 uart comms uart parity 0=none 1=odd 2=even automatically saved to non - volatile memory on write 255 (ff) 0 2 protocol mode host communications protocol 0 = select protocol based on the state of gpio input pin. 1 = multipoint packet protocol 2 = at protocol if this register contains 0, then at least one s register in the range 50 to 65 should be set to the value (14 = protocol_mode_in) so that the gpio pin cor responding to that s register automatically configures as an input and if on power up, the state of that pin is 0, then at protocol activates , oitherwise mp. if no gpio pin is configured to specify protocol and the value in this register is 0, then mp protocol is selected. automatically saves to non - volatile memory on write . all these s registers, unless specifically mentioned , become effective after a power cycle or reset. 2.3 at s registers these registers are specific to at protocol operation only and are not accessible from mp protoco l mode. any s register marked remapped is detailed with the descriptions of the mapped - to s register s . table 2 - 3 : 'at' s registers regno min max category description 0 0 15 spp rings before auto answering an incoming spp connection. setting 0 means a connection is not auto answered. 2 0x21 0x7e spp escape character used to change from data mode to command parsing mode when in a data connection. three of these cha racter enveloped by delays result in a transition from data into command mode 504 0 1 general this register controls what debug shows on the terminal program during the connection process. 0 C
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 36 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 regno min max category description 507 0 1 spp when set to 1, which is the default, t he dsr modem status input line enter s command mode and/or drop a connection. when set to 0 the dsr line is not checked for connection related functionality. this is so that the input can convey a digital status to the peer using s registers 651/654 and 661/664 inclusive. 508 remapped gap to s reg 9 009 (9 in mp mode see section standard s registers ) 509 remapped gap to s reg 9010 (10 in mp mode . s ee section standard s registers ) . 510 remapped gap to s reg 9007 (7 in mp mode . s ee section standard s registers ) 511 remapped gap to s reg 9009 (8 in mp mode . s ee section standard s registers ) . 514 2 60 pairing minimum time in seconds to wait for the conclusion of a pairing operation . 517 2 60 inquiry maximum time in seconds to perform an inquiry . 518 1 255 inquiry maximum number of inquiry responses in an inquiry . 520 remapped uart comms to s reg 9240 (240 in mp mode . see section standard s registers ) . 521 remapped uart comms to s reg 9240 (240 in mp mode . see section standard s registers ) . 522 remapped uart comms to s reg 9241 (241 in mp mode . see section standard s registers ) . 523 remapped uart comms to s reg 9242 (242 in mp mode. see section standard s registers ) . 524 remapped uart comms to s reg 92 43 (243 in mp mode. see section standard s registers ) . 530 1 60 spp reconnect delay when configured as master in auto connection mode. 531 0 3 spp/ at parser specifies the at parser mode on connection establishment. 0 = normal, that data exchanges between uart and rf . 1 = local_command. t he at interpreter parses uart input and rf data is discarded . 2 = remote_command. the at interpre ter parses rf input and uart data is discarded. if s reg 536 is not 1 then this register cannot be set to 2 and an error returns. 3= local_command. the at interpreter parses uart input and incoming rf data sends to the host using the rx asynchronous response. 561 remapped sniff mode to s reg 9073 (73 in mp mode . see section standard s registers ) .
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 37 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 regno min max category description 562 remapped sniff mode to s reg 9074 (74 in mp mode . see section standard s registers ) . 563 remapped sniff mode to s reg 9 075 (75 in mp mode see section standard s registers ) . 564 remapped sniff mode to s reg 9076 (76 in mp mode . s ee section standard s registers ) 619 0 0xffff gpio this specifies a writ e mask when ats620=x set s multiple gpio states . 620 0 0xffff gpio ats620? r ead s all the gpio states at once . ats620=x write s new gpio states using the mask in s register 619 . 621 0 0xff adc reads and digitises the voltage on aio0 and outputs it as an 8 bit number on the terminal program. 622 0 0xff adc reads and digitises the voltage on aio1 and outputs it as an 8 bit number on the terminal program. 651 - 1 8 gpio - 1 mean s no gpio pin allocation . see note 1 and 3 below. requires firmware build 185 or newer . 652 - 1 8 gpio - 1 mean s no gpio pin allocation . see note 1 and 3 below. requires firmware build 185 or newer . 653 - 1 8 gpio - 1 mean s no gpio pin allocation . see note 1 and 3 below. requires firmware build 185 or newer . 654 - 1 8 gpio - 1 mean s no gpio pin allocation . see note 1 and 3 below. requires firmware build 185 or newer . 661 - 1 8 gpio - 1 mea ns no gpio pin allocation . see note 2 and 3 below. requires firmware build 185 or newer . 662 - 1 8 gpio - 1 mean s no gpio pin allocation . see note 2 and 3 below. requires firmware build 185 or newer . 663 - 1 8 gpio - 1 mean s no gpio pin allocation . see note 2 and 3 below. requires firmware build 185 or newer . 664 - 1 8 gpio - 1 mean s no gpio pin allocation . see note 2 and 3 below. requires firmware build 185 or newer . 717 2 15 gap maximum time to wait f or a remote friendly name to read (at+bti command) . all these s registers, unless specifically mentioned , become effective after a power cycle or reset.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 38 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 note 1: s reg 651 to 654 take a gpio pin number in the range 1 to 8 inclusive (or as per the full range for the specific module) which map s from the rtr, rtc,dv,ic bits in the rfcomm modem control signal whic h exchanges for serial port profile. when a fresh modem control sig message arrives from the peer, if the corresponding s register is not - 1 and the specific gpio pin is configured as an output (using s reg 50 to 65 inclusive) , then the state of the bit output s to that pin. note 2: s reg 661 to 664 take a gpio pin number in the range 1 to 8 inclusive (or as per the full range for the specific module) which map s to the rtr, rtc,dv,ic bits in the rfcomm modem c ontrol signal which exchanges for serial port profile. if a gpio pin specifies in one of these s registers and it changes state and there is an spp connection, then the state of that input pin copies into a n rfcomm modem control message and sent to the peer. note 3: this capability enables the state o f between 2 and 4 (depends on the direction of th e connection) digital pins to exchange between peers without any host intervention.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 39 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 3 m ultipoint p rotocol 3.1 introduction to multip oint protocol this chapter describes a packet based messaging in terface which a host uses to send commands, receive responses, receive asynchronous events and exchange multiplexed data with the bluetooth serial m odul e, henceforth described as the m odule. the m odule consists of a bluetooth c hipset with an approved bluetooth stack which allows simultaneo us connections to a minimum of one slave and , depending on hardware build and conditions, up to seven slaves. it also allows connections to multiple profiles to one or more slaves. hence this document adopts a concept of channels instead of slave connections. you can also view these channels as logical data pipes. the term host in this document refers to any entity which is a source of command messages, sink for response/event messages , and both source and sink for multiplexed data packets. to further eliminate any confusion, when the terms command message and confirm message are used, it implies a message from the host to the module. likewise the terms response message and event message imply a message from the module to the host. there is an implied client/server model in the protocol described in this document and the host should ensure that n o new commands issue to the module until after a response is received for that command or an appropriate timeout . if multiple commands are sent, they queue and process only after the oldest command processes . confirm messages do not have the same restricti ons. data packets do not follow that model. it is likely that asynchronous event messages are sent before response messages but that should not be taken as a signal to issue new commands. the only exception to thi s is when an unknown command receives; in t his case the transaction terminates by an unknown_command event. this document does not describe how the packets are physically exchange d between the host and the module. the transport medium could be either uart or usb. it also does not describe the forma t of any envelope that may be required to reliably and quickly transfer the message packet between the host and module. this implies that when the packets proposed in this document are processed, they are assumed not to contain any errors by either peer en tities. 3.2 flow control & data integrity t he transport mechanis m streams in nature. if the transport medium is usb , then flow control and data integrity is inherently provided by the usb protocol. if t he medium is uart , t hen it is assumed that there is a minimum of a five wire interface: rx, tx, cts, rts , and gnd. any host attached to the uart of the module strictly observe s cts/rts hardware handshaking. packet data integrity may or may not be provided depending on the build. f or a uart transport media, guaranteeing data integrity is at the severe expense of data throughput.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 40 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 3.3 packet format this section describes the general format of incoming and outgoing packets. the term incomi ng henceforth implies packets sent by the host to the module and outgoing in the reverse direction. that is, the direction terminology is module (server) centric. all packets have octet granularity. when an octet is described as containing bit fields, i t shall be taken that bit 0 is the least significant bit and bit 7 is the most significant bit. subfields in the packe t which require multiple octets shall be ordered so that the lowest significant octet transmits last over the transport media, unless spec ifically described otherwise C this is also referred to as big e n dia n format. for e xample, a 16 - bit word value require s two octets within the packet and the first transmitted octet correspond s to the upper byte. similarly, a 6 - byte bluetooth address transp ort s the most significant byte first. if the order is reversed then it is specifically highlighted in the description of appropriate packets. subfields which are data arrays shall be described with the [ ] operator in descriptions which come in subsequen t chapters. apart from data packets, all command, confirm, respond and event packets are of fixed size. if there isnt enough data to fill a p acket, then the packet fills with 0s. the protocol and fixed packet format is optimized to ensure maximum data thr oughput over the air. subsequent sections describe the packets in detail. 3.4 host to module packets these are packets used to convey commands and confirms to the module or raw data to be sent over an open bluetooth connection. 3.5 command & confirm packets the format for command and confirm packets is displayed in table 3 - 1 . table 3 - 1 : command and confirm packets octet field description 0 length total length of this packet, including this octet 1 channel always zero 2 cmd_id/cnf_id described in the subsequent chapters and have cmd_ or cnf_ prefixes 3 flow_in bit 0 to 6 specify a mask. a clear bit means the module should not send any more packets to that corresponding spp data channel. bit 7 is always zero and is used as an extension bit in the future. it is assumed that the host is always able to receive a response or status packet. 4..n data[] data as required and has meaning specific to cmd_id or cnf_id. for example, if the command is to make a connecti on to a peer device, then it is at least a six octet array specifying the bluetooth address of the peer. the value of cmd_id is in the range of 0 to 63 and commands are queued until a previous command is completed by sending a response packet to the host. the value of cnf_id is in the range of 64 to 127 inclusive. unknown command values result in an evt_unknown_command event, with the command value reflected in the data field. if the octet value is specified in the range 128 to 255 (0x80 to 0xff), then
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 41 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 reflecting that value in the data field of an evt_unknown_comman d instead of the command field of a response packet guarantees that the packet is not mistakenly processed as an event. confirm packets are not queued by the uart packe t processor in the module and are processed as soon they are received. as an example, t his allows passkeys and pincodes to submit to the module while a response is awaited by the cmd_connection_make command. in other words , confirm packets always go to the head of the packet queue. 3.6 data packets the format for data packe ts is displayed in table 3 - 2 and can arrive at any time; that is, they do not adhere to a client/server model. the only method by which the host can b e stopped from sending this message is by sending a zero value in the flow_out field of a response or status message. the module is prepared to receive at least one data packet after deasserting the appropriate flow control bit. table 3 - 2 : data packet format octet field description 0 length total length of this packet, including this octet 1 channel 0 is an invalid value as this marks the packet as command/response or event. 1 to 7 are dedicated serial port profile connections . 128 is dedicated as hid device data channel . all other chann els are reserved for future use. 2..n data[] for channels 1 to 7, this data array unconditionally sends over the air in the appropriate spp connection for channel 128 data is interpreted before appropriate hit reports transmit. 3.7 packet processing logic data and confirm packets process as soon as they are received. a command packet processes in a transaction, meaning it processes as soon as it is received if and only if there is no previous command processing and waiting for completion. completion happens when an appropriate response packet is sent to the host. if a command transaction is currentl y in progress, then the packet ins erts in a first - in, first - out queue. when an on - going command transaction complete s , the queue is inspected and , if non - empty , the oldest que ued command is processed . 3.7.1 module to host packets these packets convey responses or e vents from the module and raw data received over an open bluetooth conn ection or internal data source. response packets are always a result of a comm and packet and event packets asynchronously send to the host as and when required. the host shall ensure that it is always ready to accept response and event packets, especially event packets as they can be sent at any time including where there is an incomplete transaction in progress. 3.7.2 response packets the for mat for response packe ts is displayed in table 3 - 3 . table 3 - 3 : response packet format octet field description
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 42 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 0 length total length of this packet, including this octet 1 channel always zero 2 cmd_id echoed from the command packet (shall be > 0 and < 128) 3 flow_out bit 0 to 6 specify a mask. a clear bit means the host should not send any more packets to that corresponding data channel. bit 7 is always 0 and i s an extension bit in the future. 4 status zero means success, otherwise see section status values n..m data[] data as required and has meaning specific to the response for cmd_id 3.7.3 event packets the format for event packets is displayed in table 3 - 4 . table 3 - 4 : event packet format octet field description 0 length total length of this packet, including this octet 1 channel always zero 2 evt_id described in subsequent chapters, but bit 7 is always set, hence >= 128 3 flow_out bit 0 to 6 specify a mask. a clear bit means the host should not send any more packets to that corresponding data channel. bit 7 is always zero and is an extension bit in the future. n..m data[] data as required and has meaning specific to the response for evt_id the only difference between a response and an event packet is that octet 2 is defined as cmd_id in the former and evt_id in the latter ; in addition , the status field is missing in the event packet. the value of cmd_id will be in the range 0 to 0x3f and evt_id will take values in the range 0x80 to 0xff. thi s allows bit 7 of that octet to be decoded whether the packet is a response packet or an event packet. the value of status is in the range of 0 to 255. a value of zero means s uccess and any other value is a failure, where the value gives more details of the failure type. the values of status are d efined in a c header file which can be obtained on request from laird.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 43 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 3.7.4 data packets the format for data packets is displayed in table 3 - 5 . the only method by which the host can stop the module from sending this message is by sending a zero value in the flow_in field of command message , and even that is only for channels 1 to 7 inclusive. table 3 - 5 : data packet format octet field description 0 length total length of this packet, including this octet 1 channel 0 is an invalid value as this marks the packet as command/response or event. the channel number is allocated as follows: 1 to 7 are dedicated serial port profile connections. 0x20, 0x80, 0x90..0x97,0xa0 are dedicated as hid data channels. 0x98..0x9f are dedicated for blob sending and receiving data from blobs. 0xb0 conveys hdp data and 0xb1 is a hdp continuation data channel. 0xf0 convey s enhanced inquiry response data to the host. all other channels are reserved for future use. 2..n data[] data to be processed for channel channel . data pa ckets are symmetrical in format in both directions. note: o nly data channels 1 to 7 inclusive have flow control via the flow_in and flow_out fields of command /confirm and response/event packets. 3.7.5 data channel numbers table 3 - 6 summarizes channel id allocation for various connections and profiles. table 3 - 6 : channel id allocation channel number profile comments 0x0 - all traffic routed to/from the protocol parser C C C C
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 44 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 note 2: this channel is used for canned hid keyboard device reports. data in this channel is interpreted as ascii and for each ascii char acter two input reports send to the host C the first being the press event and the second the unpress event. if the ascii value is in the range 0x7f to 0xff then it is silently discarded. note 3: this channel is used for raw hid device input reports. for example, if the built - in keyboard hid descriptor is active then the in put report is eight bytes long. if a ho st sends an output report it appear s in this channel as a single data packet . it is essential that all input or output reports maintain the packet boundaries. note 4: these channels are used to receive input reports f rom hids and send output reports when the module configures as an hid host. the size and format of the reports shall be as per the hid descriptor that is active on that channel. note 5: these channels are used to send and receive data from blobs (binary lo ng objects) which are arbitrary length data buffers. if a blob does not exist, then the data sent on that channel is silently discarded. the blobs are identified by a 0 - based index number; to send data to blob 0, channel 0x98 is used and 0x99 for blob 1. o nce data uploads into a blob, then cmd_blobmanage manipulates that data. for example, the blob mechanism uploads new hid device descriptors into the module.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 45 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 3.7.6 host packet receive flowchart as optimal data throughput is t he design goal, the format and detail of packets have been constructed appropriately. it is recommended that the host implement the following flowchart, for rapid servicin g and flow control of packets. figure 3 - 1 : host packet receive flowchart on packet receive pkt[2] & 0x80 ==0 pkt[1] ==0 yes (command) no (data) yes (response) no (event) len >= 5 len >= 4 process data len > 2 yes yes yes process response process event evt == unknown_cmd end yes module will be ready to recieve new command module will be ready to recieve new command
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 46 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 3.8 host command/responses this section describes all host commands and confirms in detail what is s pecified via the cmd_id/cnf_id field of all command and confirm p ackets. the description for each command/confirm below is in the form of a command or confirm packet table and a corresponding response packet table when appropriate. each command has a unique cmd_id value in the range 1 to 63 (0x01 to 0x3f). 0 is reserved and confirm s a cnf_id in the range 64 to 127 (0x40 to 0x7f). the actual value of cmd_id in the value column is described as [descriptive_name] where descriptive_name can be found in a c header file which can be obtained on request from laird. the va lue of status is similarly defined in a header file which can also be obtained from laird. the commands are grouped as : ? informational ? configuration ? connection ? inquiry ? pairing ? miscellaneous they are described in subsequent sub chapters. 3.9 information commands this group of commands obtain s information about the module. 3.9.1 no operation this command results in no action other than to convey new flow_in status to the module and get a response packet with the latest status for the flow_out bits. it is expected that a host uses this packet to poll for a change in the flow bits. command packet offset field value comments 0 length 4 fixed 1 channel 0 fixed 2 command [cmd_no_operation] 3 flow_in ?? runtime value
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 47 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 response packet offset field value comments 0 length 5 1 channel 0 2 command [cmd_no_operation] 3 flow_out ?? runtime value 4 status [ok] or [invalid_license] 3.9.2 g et connectable, discoverable, security modes this command get s the current connectable, discoverable , and security modes. command packet offset field value comments 0 length 4 fixed 1 channel 0 fixed 2 command [cmd_get_modes] 3 flow_in ?? runtime value response packet offset field value comments 0 length 8 1 channel 0 2 command [cmd_get_modes] 3 flow_out ?? runtime value 4 status ok or invalid_license 5 discmode 0..3 bit 0: 1 for discoverable mode bit 1: 0 for generic, 1 for limited discovery mode. bits 4..7: future use specifying which limited inquiry access code to use. 6 connmode 0..3 bit 0: 1 for connectable mode bit 1: 1 for auto accept channe l 7 secmode 12..15 12 = ssp + io_cap_no_input_no_output 13 = ssp + io_cap_display_yes_no 14 = ssp + io_cap_keyboard_only 15 = ssp + io_cap_display_only note 1: secmode is now driven by the simple secure pairing procedure included in and after v.2.1 of the bt specification.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 48 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 note 2: for secmode, the no i/o capability option is equivalent to the just works scenario in ssp. note 3: when this module interacts with a pre - 2.1 device, it is unconditionally forced into legacy pairing mode. note 4: laird recommends that the reader become familiar with the ssp concept introdu ced in all subsequent version of bt (post v2.1). the best introduction is to google the phrase bluetooth simple secure pairing . note 5: contact laird for an informal discussion if necessary. 3.9.3 read local bluetooth address this command read s the bluetooth address of the module. command packet offset field value comments 0 length 4 fixed 1 channel 0 fixed 2 command [cmd_read_bluetooth_address] 3 flow_in ?? runtime value response packet offset field value comments 0 length 11 fixed 1 channel 0 fixed 2 command [cmd_read_bluetooth_address] 3 flow_out ?? runtime value 4 status [ok] 5..10 bdaddr[] nap[0,1]:uap[2]:lap[3,4,5] bluetooth address 3.9.4 information this command extract s information from the module, for example version number. command packet offset field value comments 0 length 5 fixed 1 channel 0 fixed 2 command [cmd_information] 3 flow_in ?? runtime value 4 infotype 0..255
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 49 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 response packet offset field value comments 0 length 14 fixed 1 channel 0 fixed 2 command [cmd_information] 3 flow_out ?? runtime value 4 status [ok] 5 infotype 0..255 echoed from command 6.13 data[8] as per the table below the type of information requested is specified by the infotype parameter, as per the table below. infotype = get_version (0) offset field name range comments 0 format/firmware/platform id 0..255 bit 7: 1 bit654: spare bit3210: firmware/platform id 1 stack_major 0..255 ccl version number index 2 app_major 0..255 laird application version number index 3 developer/branch id 0..255 bit7654: developer id bit3210: branch id 4..5 msb/lsb of build numb er 0..65535 odd number == engineering even number == production 6 reserved 0..255 laird private use 7 twig number/sdk id 0..255 b7654321 : twig number b1 : laird private use infotype = get_manufacturer (1) offset field name range comments 0..7 manufacturer/stack information e.g. csr/ccl chip manufacturer, null terminated string
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 50 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 infotype = get_chip_info (2) offset field name range comments 0..7 chip designation e.g. bc4 - ext chip designation, null terminated string infotype = get_physical_medium (3) offset field name range comments 0 physical medium 0 0=bluetooth 1..7 reserved 0 infotype = get_hardware_platformid (100, 0x64) offset field name range comments 0 hardware id (msb) 0..255 1 hardware id (lsb) 0..255 2..7 unused, set to 0s hardware id is 0x0100 for the btm4xx series module . infotype = memory pools (224..239 0xe0..0xef) offset field name range comments 0..1 pool block size e.g. 0004 size of block 2..3 available blocks e.g. 1234 available and free to use infotype = ccl stack trunk version (240 0xf0) offset field name range comments 6..7 stack trunk version e.g. 1234 trunk version of ccl stack infotype = ccl stack branch version (241 0xf1) offset field name range comments 6..7 stack branch version e.g. 1234 branch version of ccl stack infotype = ccl stack vena version (248 0xf8) offset field name range comments 6..7 stack vena version e.g. 1234 vena version of ccl stack
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 51 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 3.10 configuration commands this group of commands configure s the module. 3.10.1 read s register configure t he module using 32 bit integer values , which can be stored in non - volatile memory. valid register num bers are in the range 0 to 255. see the s registers section fo r a full list of all registers. the following command read s the current value of the s register regno. command packet offset field value comments 0 length 5 fixed 1 channel 0 fixed 2 command [cmd_read_sreg] 3 flow_in ?? runtime value 4 regno 0 to 255 response packet offset field value comments 0 length 10 fixed 1 channel 0 fixed 2 command [cmd_read_sreg] 3 flow_out ?? runtime value 4 status as appropriate 5 regno 0 to 255 echoed from command 6..9 regval[] register value regval[0] is the most significant octet. 3.10.2 write s register this command write s a new value to the s register regno. see the s registers section for a full list of all registers. command packet offset field value comments 0 length 9 fixed 1 channel 0 fixed 2 command [cmd_write_sreg] 3 flow_in ?? runtime value 4 regno 0 to 255 5..8 regval[] new register value regval[0] is the most significant octet.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 52 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 response packet offset field value comments 0 length 10 1 channel 0 2 command [cmd_write_sreg] 3 flow_out ?? runtime value 4 status as appropriate 5 regno 0 to 255 echoed from command 6..9 regval[] register value regval[0] is the most significant octet. 3.10.3 store s registers this command save s current s register values in cache into non - volatile memory so they survive power cycle. command packet offset field value comments 0 length 4 fixed 1 channel 0 fixed 2 command [cmd_store_sreg] 3 flow_in ?? runtime value response packet offset field value comments 0 length 5 fixed 1 channel 0 fixed 2 command [cmd_store_sreg_] 3 flow_out ?? runtime value 4 status as appropriate 3.10.4 default s registers this command force s all s register values in cache to factory defaults. command packet offset field value comments 0 length 4 fixed 1 channel 0 fixed 2 command [cmd_ default_sreg] 3 flow_in ?? runtime value response packet offset field value comments 0 length 5 fixed 1 channel 0 fixed 2 command [cmd_ default_sreg_] 3 flow_out ?? runtime value 4 status as appropriate 3.11 connection commands this group of commands manage s connections.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 53 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 3.11.1 set connectable mode this command enable s /disable s connectable mode and specifies auto accept parameters for channels and muxs . command packet offset field value comments 0 length 6 fixed 1 channel 0 fixed 2 command [cmd_ connectable_mode] 3 flow_in ?? runtime value 4 enable 0..1, 0xff 0 = disable, 1=enable 0xff = read current mode 5 accept bit mask bit 0: set to auto accept channel setup bit 1..7: reserved for future use if bit 0 is set then it overrides sreg 14 , otherwise that s register is consulted or incoming con nections. response packet offset field value comments 0 length 6 fixed 1 channel 0 fixed 2 command [cmd_ connectable_mode] 3 flow_out ?? runtime value 4 status as appropriate 5 curmode 0..1 0 = not connectable 1 = connectable 3.11.2 service incoming connection when the module is in connectable mode, incoming connection requests pass to the host via an evt_connection_setup message C if and only if autoaccept is not enabled (via command or s register 14). the host ac cepts or rejects the remote connection request using this message. command packet offset field value comments 0 length 12 fixed 1 channel 0 fixed 2 command [cmd_ connection_setup] 3 flow_in ?? runtime value 4..9 bdaddr[] nap[0,1]:uap[2]:lap[3,4,5] bluetooth addr 10 handle 0..255 can be any value the host wants to set. this value is echoed by the module in the response. 11 accept 0..1 0 = reject. 1..255 = accept
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 54 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 response packet offset field value comments 0 length 6 fixed 1 channel 0 fixed 2 command [cmd_ connection_setup] 3 flow_out ?? runtime value 4 status as appropriate 5 handle 0..255 echoed from the command receipt of the response is not an indi cation that the connection has established. if the connection is to be accepted, the module send s evt_incoming_connection when the connection is fully establishe d , as shown in the message sequence chart below . figure 3 - 2 : service incoming connection sequence diagram note: if auto accept was specified when the module was put into connectable mode, then for incoming connections there is only an evt_incoming_connection message. figure 3 - 3 : service incoming con nection with auto accept specified host module rsp_connection_setup (handle) cmd_connection_setup (bdaddr,accept,handle) evt_connection_setup (bdaddr) connection established incoming connection evt_incoming_connection (channelid, bdaddr, uuid) connection established evt_incoming_connection (channelid, bdaddr, uuid) incoming connection host module
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 55 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 3.11.3 make outgoing connection this command make s an outgoing connection to a profile in the remote peer. command packet offset field value comments 0 length 13 fixed 1 channel 0 fixed 2 command [cmd_ make_connection] 3 flow_in ?? runtime value 4 handle 0..255 can be any value the host wants to set. this value is echoed by the module in the response. 5..10 bdaddr[] nap[0,1]:uap[2]:lap[3,4,5] bluetooth address 11..12 uuid[] 0x1101(spp) 0x1124(hid) uuid of the profile to connect to. offset 11 is the msb. 13 rfu 0 always set to zero response packet offset field value comments 0 length 7 fixed 1 channel 0 fixed 2 command [cmd_ make_connection] 3 flow_out ?? runtime value 4 status as appropriate 5 handle 0..255 echoed from the command 6 channel 1..7 (spp) 0x20,0x9x,0xa0 (hid device) channel i d to be used for subsequent spp data packets, and also when dropping the connection if the status field in the response is mpstatus_ok, then a connection successfully established. any other value is a failure. t he content of s register 11 specifies the max frame size to be used by the lower layers. figure 3 - 4 : make outgoing c onnection sequence diagram when at least one connection is active (regardless of prof ile) , the dcd output pin asserts .
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 56 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 3.11.4 drop connection this comma nd destroy s an existing channel. command packet offset field value comments 0 length 6 fixed 1 channel 0 fixed 2 command [cmd_ drop_connection] 3 flow_in ?? runtime value 4 handle 0..255 can be any value the host wants to set. this value is echoed by the module in the response. 5 channel 1..7, as appropriate for other profiles as was specified in either rsp_make_connection or evt_incomming_connection response packet offset field value comments 0 length fixed 1 channel 0 fixed 2 command [cmd_ drop_connection] 3 flow_out ?? runtime value 4 status as appropriate 5 handle 0..255 echoed from the command if the status field in the response is mpstatus_ok, then the request to drop the channel successfully submitted to the lower layers of the stack. when the channel drops , an evt_disconnect event sends to the host. when at least one connection is active (regardless of profile) the dcd output pin remain s asserted. figure 3 - 5 : drop connection sequence diagram
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 57 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 3.12 set modem lines bluetooth serial port profile is capable of exchanging modem signals dtr, dsr, rts, cts, dcd , and ri over air. from a hosts perspective, it can have dtr, rts, dcd and ri as output lines. note: dcd and ri are outputs for modems and host in this context can mean either a pc or a peripheral like a modem . additionally uarts are capable of sending break signals. break output signals are non - idle state tx pin s for a period much greater than the character width at the current baud rate setting. this command send s dtr, rts, dcd , and ri states to the peer device and also to specify a break C future feature. command packet offset field value comments 0 length 7 fixed 1 channel 0 fixed 2 command [cmd_ controlmodemlines] 3 flow_in ?? runtime value 4 channel 1..7 channel id of an open channel 5 modem bit mask bit 0: dtr state bit 1: rts state bit 2: dcd state bit 3: ri state bits 4 .. 7 : ignored 6 break 0 not available response packet offset field value comments 0 length 6 fixed 1 channel 0 fixed 2 command [cmd_ controlmodemlines] 3 flow_out ?? runtime value 4 status as appropriate 5 channel 1..7 echoed from command the status value is mpstatus_ok if the message succeeded . modem signals sent by the peer device present to the host in the message evt_modem_status defined in subsequent chapters. note: break signal capability is currently not provided by the lower stack, and so it is mentioned in the context of this command message for future implementation.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 58 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 3.12.1 rssi and link quality this command obtain s the rssi and link quality values for a given open connection. this is a parameter associated with the acl connection to a peer device and does not have any meaning with channel id s. command packet offset field value comments 0 length 10 fixed 1 channel 0 fixed 2 command [cmd_rssi_linkqual] 3 flow_in ?? runtime value 4..9 bdaddr[] nap[0,1]:uap[2]:lap[3,4,5] bluetooth addr response packet offset field value comments 0 length fixed 1 channel 0 fixed 2 command [cmd_rssi_linkqual] 3 flow_out ?? runtime value 4 status as appropriate 5..10 bdaddr[] nap[0,1]:uap[2]:lap[3,4,5] bluetooth addr 11 rssi - 128 to 127 rssi value. is zero if the signal is within the golden range 12 linkqual 0 C 255 the definitions of rssi and linkqual are paraphrased from the blue tooth specification as follows: 3.12.1.1 rssi this value is the difference between the measured received signal strength indication (rssi) and the limits of the golden receive power range (see golden receive power range ). any positive rssi value returned by the host controller indicates how many db th e rssi is above the upper limit; any negative value indicates how many db the rssi is below the lower limit. a value of zero indicates that the rssi is inside the golden receive power range. note: h ow accurate the db values are depends on the bluetooth hardware. the only requirements for the hardware are that the bluetooth device is able to tell whether the rssi is inside, above or below the golden device power range. 3.12.1.2 golden receive power range the lower threshold level of the golden receive power range corresponds to a received power between - 56 dbm and 6 db above the actual sensitivity of the receiver. the upper threshold level is 20 db above the lower threshold level to an accuracy of +/ - 6 db .
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 59 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 3.12.1.3 link quality link_ quality is a value from 0 - 255, which represents the quality of the link between two bluetooth devices. the higher the value, the better the link quality. e ach bluetooth module vendor determine s how to measure the link quality. in the case of csr, this valu e is a measure of ber (bit error rate). 3.13 get open channel list this comman d obtain s a list of channel ids corresponding to connections which are open. it is a good method of querying the module to see how many bluetooth connect ions are established and their corresponding channel id numbers. a host should not need to use this command as it should be keeping track of the following two events and responses: evt_disconnect, evt_connection_setup, rsp_make_connection. command packet offset field value comments 0 length 10 fixed 1 channel 0 fixed 2 command [cmd_channel_list] 3 flow_in ?? runtime value response packet offset field value comments 0 length 22 fixed 1 channel 0 fixed 2 command [cmd_channel_list] 3 flow_out ?? runtime value 4 status as appropriate 5 count 0..n number of connections which have been established 6..21 channel id list[16] array of 16 bytes a nonzero value implies a connection exists and the array element value identifies the channel id 3.14 inquiry commands this group of commands performs inquiries and puts the module into discoverable mode. 3.14.1 inquiry request this command perform s a bluetooth inquiry. command packet
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 60 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 offset field value comments 0 length 7 fixed 1 channel 0 fixed 2 command [cmd_inquiry_req] 3 flow_in ?? runtime value 4 maxresp 1..255 maximum number of responses before aborting the inquiry procedure 5 timeout 1..120 t ime in seconds, before aborting the inquiry procedure. 6 flags 0..1 bit 0 : 1 t o allow repeat addresses. bits 1..6 r eserved for future bit 7 : get enhanced inquiry responses response packet offset field value comments 0 length 7 fixed 1 channel 0 fixed 2 command [cmd_inquiry_req] 3 flow_out ?? runtime value 4 status as appropriate 5 total ?? the total number of inquiry responses that were received from peers. 6 dump ?? the total number of inquiry result events that were not sent because the transmit buffer of the module was full. this is a result of the host deasserting its rts line. as a result of this command, as and when peer devices respond with inquiry responses, for each inquiry response, if bit 7 of the flags field is zero then an event evt_inquiry_result is s ent to the host. if b it 7 of flags field is one then, given that enhanced inquiry data has variable length data for any given response, the entire inquiry response is s ent via data channel 0xf0 to the host, with format described in subsection s below. when the number of command - specified inquiry responses are received or the specified time has elapsed, the final response is sent to indicate to the host that the inquiry procedure is complete. if the dump field in the response is non - zero , it is indicatin g that the host is not reading its receive buffer fast enough and is resulting in rts deasserting towards the module. flags bit 1 - 4 in future are to specify a limited access code inquiry . see message sequence diagram ( figure 3 - 6 ) which illustrates that the rsp_inquiry_req message terminates the inquiry process. 3.14.2 enhanced inquiry data packet format when enhanced inquiry responses are requested via flags bit 7 be ing set, each inquiry response sends to the host in data channel 0xf0 and the packet is formatted as follows:
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 61 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 ll f0 aaaaaaaaaaaa cccccc rr ee.ee where:: ll is the total length of the pack et, and given only the ee..ee field is of variable length, the length of the ee..ee field is calculated by subtracting 12 (decimal) from ll. f0 is the channel number and is fixed aaaaaaaaaaaa is a 6 byte field containing the bluetooth address of the respo nding device. cccccc is the device class code of the responding device rr is the measured rssi value for that response (8 bit signed integer) ee..ee is a variable length field, with a maximum of 240 bytes, containing the enhanced inquiry data which is formatted as multiple len/tag/data structures as specified in the bluetooth specification. where both len and tag fields are single bytes and len does n ot include itself. any data passed from the baseband must match the format defined in the bluetooth specification version 2.1 + edr [1], vol3, part c C generic access profile, 8 extended inquiry response data format (page 1305 in the *.pdf file). a typica l messa ge sequence is as follows: figure 3 - 6 : typical message sequence 3.14.3 set discoverable mode this command enable s /disable s discoverable mode. command packet offset field value comments 0 length 5 fixed 1 channel 0 fixed
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 62 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 2 command [cmd_ discoverable_mode] 3 flow_in ?? runtime value 4 mode 0..1, 0xff 0 = disable, 1 = generic access code 0xff = read current mode response packet offset field value comments 0 length 6 fixed 1 channel 0 fixed 2 command [cmd_ discoverable_mode] 3 flow_out ?? runtime value 4 status as appropriate 5 curmode 0..1 1 = generic access code the module use s the parameters stored in s registers 7 and 8 to set the inquiry scan interval and win dow. inquiry scan is how often (interval) the radio listen s for an inquirer and for how long (window) each time. 3.15 pairing commands this group of commands manage s either inco ming or outgoing pairings and the trusted device database which resides in the non - volatile memory of the module. the trusted device database is a database with two tables, each with records of two fields. one field is the blue tooth address of a paired device and the other store s the 16 byte link key. one database is classed a rolling database and store s new pairing information as they happen. if the database is full, then the oldest is discarded to make space for the latest on e. the other database is classed as a persistant database which stores pairing information which can only be deleted when a new pairing initiates to that particular device or on request from the host. the host protocol provides for a command to transfer a record between these two databases. in addition there is a command for the host to determine if a device is trusted. there is also a command to manually insert a device and its link key into the database. depending on the peer device, either a legacy pairi ng procedure or a simple secure pairing occurs . a legacy pairing occurs if the peer device is older than v2.1 of the bluetooth specification. simple secure pairing (for v2.1 and newer devices) uses a diffie - hellman procedure to exchange the secret link key , but is vulnerable to man - in - the - middle attack. when pairing initiate s and a legacy 2.0 or older device is not involved, then the basebands perform an i/o capability negotiation with each other to see whether it shall perform a just works unauthenticate d pairing with no man - in - the - middle (mitm) protection or an authenticated pairing which requires user interaction. the i/o capability is one of : ? display only ? keyboard only ? display with yes/no button for example:
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 63 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 if one end has display only, but the other end has keyboard only, then the negotiation results in one end displaying a six digit passcode on the display only side, which is then required to be entered at the keyboard only end. if both ends have display wi th yes/no, then duri ng the procedure both ends display a six digit passcode which needs to be visually compared and then the yes/no buttons are used to confirm that they match . this provides for a one in a million probability that a mitm attach is successf ul. to enable this new interaction with a user during pairing a new evt_s imple_pairing was defined. 3.15.1 pair initiate this command initiate s a pairing with a peer device which is assumed to be ready and waiting for a pairing. if that device is compliant with v2.0 and older of the bluetooth specifica tion then a legacy pairing result s and the pincode pin[] in this message is used otherwise there is a simple pairing procedure. command packet offset field value comments 0 length 28 fixed 1 channel 0 fixed 2 command [cmd_ pair_initiate] 3 flow_in ?? runtime value 4 timeout 5..120 pairing timeout in seconds 5..10 bdaddr[] nap[0,1]:uap[2]:lap[3,4,5] bluetooth addr of device to be paired 11..27 pin[] 17 byte string array null terminated pin code string. max imum pin code length is 16. response packet offset field value comments 0 length 5 fixed 1 channel 0 fixed 2 command [cmd_ pair_initiate] 3 flow_out ?? runtime value 4 status as appropriate if pairing is successful , the event message evt_link_key or evt_link_key_ex is s ent to the host before the response to close the procedure, as shown in the message sequence chart below. pair initiate may fail if there are any existing open connections. the status byte in the response will have an appropriate value. 3.15.1.1 simple secure pairing just works the message sequence diagram for just works when the device has specified no i/o capability is as follows:
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 64 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 figure 3 - 7 : just works sequence diagram the evt_simple_pairing displays a success/fail indication. if it fails, then the evt_link_key event does not send to the host. 3.15.1.2 simple secure pairing display yes/no the message sequence diagram for when the device has display and yes/no capability is as follows: figure 3 - 8 : display yes/no capability sequence diagram the first evt_simple_pairing contains a passcode that needs to be confirmed by the host. to confirm the passcode, the host se nd s a cnf_simple_pairing packet which has a passcode value of 00000001 ; to reject it, use s a value of 00000000. if pairing is successful, another evt_simple_pairing with a success value is sent and then a evt_link_key event is sent to the host; if not t he second evt_simple_pairing displays a 00000000 value. 3.15.1.3 simple secure pairing display only the message sequence diagram for when the device has display only capability is as follows:
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 65 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 figure 3 - 9 : display only sequence diagram the first evt_simple_pairing contai ns the passcode which must be displayed . when the peer confirms the passcode or otherwise , a second evt_simple_pairing is sent to the host with an appropriate success/fail code. if pairi ng is successful, evt_link_key is sent to the host; if not rsp_pair_initiate indicate s a non - ok status code. 3.15.1.4 simple secure pairing keyboard only the message sequence diagram for when the device has keyboard only capability is as follows: figure 3 - 10 : keyboard only sequence diagram the first evt_simple_pairing indicates that a simpl e pairing procedure h as started; at that point the host responds with a confirm packet which contains the passcode that was visually obtained from the peer devic e (o r both peers decided to use the same code). when the peer confirms the pairing a second evt_simple_pairing is se nt to the host with an appropriate success/fail code. if pairing is successful, evt_link_key is sent to the host; if not , rsp_pair_initiate indicate s a non - ok status code. 3.15.2 incoming pairing procedure as long as the module is in connectable mode (see cmd_connectable_mode) it can accept pairing from peers.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 66 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 in that situation, when a pairing procedure is detected, a pincode r equest event packet is sent to the host and the host responds with a cmd_pincode or cnf_pincode command as shown in the message sequence diagram below ( figure 3 - 11 ) . it respond s with cnf_pincode if it is in the middle of making a connection and a response for make connection is still pending. if the host does not send a pincode command , then the peer that initiated the pairing eventually timeout s . 3.15.2.1 legacy pairing the message sequence diagram for incomin g legacy pairing is as follows: figure 3 - 11 : legacy pairing sequence diagram 3.15.2.2 si mple secure pairing just works the message sequence diagram for just works when the device has specified no i/o capability is as follows: figure 3 - 12 : just wor ks with no i/o capability sequence diagram the evt_simple_pairing displays a success indication. 3.15.2.3 simple secure pairing display yes/no the message sequence diagram for when the device has display and yes/no capability is as follows :
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 67 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 figure 3 - 13 : ssp, display yes/no sequence diagram the first evt_simple_pairing contains a passcode that must be confirmed by the host. to confirm the passcode, the host send s a cnf _simple_pairing p acket which echoes the passcode. to reject it, the host use s any non - matching value. if pairing is successful, another evt_simple_pairing with a success value is sent and then a evt_link_key event is sent to the host, if not t he second evt _simple_pairing displays a 00000000 value. 3.15.2.4 simple secure pairing display only the message sequence diagram for when the device has display only capability is as follows: figure 3 - 14 : ssp, display only sequence diagram the first evt_simple_pairing contains the passcode which must display . when the peer confirms the passcode or otherwise a second evt_simple_pairing is sent to the host with an appropriate success/fail code. if pairing is succe ssful, evt_link_key is sent to the host; if not rsp_pair_initi ate indicate s a non - ok status code . 3.15.2.5 simple secure pairing keyboard only the message sequence diagram for when the device has keyboard only capability is as follows:
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 68 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 figure 3 - 15 : ssp, keyboard only sequence diagram the first evt_simple_pairing indicates that a simple pairing proced ure star ted and at that point the host respond s with a confirm packet which contains the passcode that was visually obtained from the peer device (o r both peers decided to use the same code). when the peer confirms the pairing , a second evt_simple_pairing is sent to the host with an appropriate success/fail code. if pairing is succe ssful, evt_link_key is sent to the host; if not rsp_pair_initiate indicate s a non - ok status code. 3.15.3 simple pairing confirmation this confirmatio n packet provide s a response to the module as a result of a evt_simple_pairing event and convey s to the module additional information required to complete a simple pairing procedure. this is a confirmation packet and does not result in a response from the module. event packet offset field value comments 0 length 15 1 channel 0 2 event [cnf_ simple_pairing] 3 flow_out ?? runtime value 4..9 bdaddr[6] nap[0,1]:uap[2]:lap[3,4,5] bluetooth address of pairing device 10 action 2..3 see description below 11..14 actionval 4 bytes see description below action :: 0 & 1 this is illegal and is ignored by the module. action :: 2 this informs the module the response to a yes/no query. set actionval to 00000000 for no and non - 00000000 for yes.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 69 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 action :: 3 this informs the module the response to a passcode query . in this case the actionval convey s the passcode value. note: a successful connection to an unpaired 2.1 and newer device requires t his confirmation pack et because the mp protocol does not process new commands unless the previous command was completed by sending an appropriate response packet. the packet processor in the module queues all commands until a response sends , but processes confirmation packets as they co me. 3.15.4 pincode (command) this command send s a pincode in response to an evt_pincode_request message and result s in a rsp_pincode from the module to the host. this command can also register a pincode for all subsequent incoming legacy pairings from bt2.0 and older devices. in that case the bdaddr[] field must be set to all zeros. command packet offset field value comments 0 length 27 fixed 1 channel 0 fixed 2 command [cmd_pincode] 3 flow_in ?? runtime value 4..9 bdaddr[] nap[0,1]:uap[2]:lap[3,4,5] bluetooth address of device requesting the pairing 10..26 pin[] 17 byte string array null terminated pin code string. max pin code length is 16. response packet offset field value comments 0 length 5 fixed 1 channel 0 fixed 2 command [cmd_pincode] 3 flow_out ?? runtime value 4 status as appropriate if pairing is successful the event message evt_link_key or evt_link_key_ex sends to the host after the response. the latter event sends if s register 47 is set to 1. 3.15.5 pincode (confirmation) this is a confirmation packet which send s a pincode in response to an evt_pincode_request message while making an outgoing connection to a legacy pairing device and there was a pairing challenge by the peer prior to connection acceptance.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 70 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 this packet, just like the command version of this packet, can also register a pincode for all subsequent incoming legacy pairings from bt2.0 and older devices. in that case the bdaddr[] field must be set to all zeros. command packet offset field value comments 0 length 27 fixed 1 channel 0 fixed 2 command [cmd_pincode] 3 flow_in ?? runtime value 4..9 bdaddr[] nap[0,1]:uap[2]:lap[3,4,5] bluetooth address of device requesting the pairing 10..26 pin[] 17 byte string array null terminated pin code string. max pin code length is 16. if pairing is successful , the event message evt_link_key or evt_link_key_ex is sent to the host after the response. the latter event sends if s register 47 is set to one . note: a successful connection to an unpaired 2.0 and newer device requires this confirmation packet because the mp protocol does not process new commands unless the previous command was completed by sending an appropriate response packet. the packet processor in t he module queues all commands until a response sends , but processes confirmation packets as they come hence in this case cmd_pincode does not work. 3.15.6 trusted database record count this command obtain s the number of trusted devices in the database specified. command packet offset field value comments 0 length 5 fixed 1 channel 0 fixed 2 command [cmd_ trusted_db_count] 3 flow_in ?? runtime value 4 dbtype 0..1 0 = rolling database 1 = persistant database response packet offset field value comments 0 length 8 fixed 1 channel 0 fixed 2 command [cmd_ trusted_db_count] 3 flow_out ?? runtime value 4 status as appropriate 5 dbtype 0..1 echoed from command 6 count 0..n number of trusted devices in this database 7 maxcount 0..n maximum number of devices that can be
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 71 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 stored in this database note : rolling database store s all new pairings automatically. it is up to the host to transfer a record from rolling to the persistant database so that it does not get overwritten. 3.15.7 trusted database read record this command read s the bluetooth address of the itemno pairing in the database specified, counted from the top. itemno is indexed from one . command packet offs et field value comments 0 length 6 fixed 1 channel 0 fixed 2 command [cmd_trusted_db_read] 3 flow_in ?? runtime value 4 dbtype 0..1 0 = rolling database 1 = persistant database 5 itemno 1..n item number to read response packet offse t field value comments 0 length 13 fixed 1 channel 0 fixed 2 command [cmd_trusted_db_read] 3 flow_out ?? runtime value 4 status as appropriate 5 dbtype 0..1 echoed from command 6 itemno 1..n echoed from command 7..12 bdaddr[] nap[0,1]:uap[2]:lap[3,4,5] bluetooth addr is zeros if specified item does not exist if s reg 47 is set to one , then it is possible to read a record so that both the address and link key information is supplied by sending the command cmd_ trusted_db_istrusted. in that case , the event evt_link_key_ex is sent before the response to cmd_trusted_db_istrusted. 3.15.8 trusted database delete record this command delete s a pairing from the databases. it is not necessary to specify the database type, as both databases are scanned. command packet offset field value comments 0 length 10 fixed 1 channel 0 fixed 2 command [cmd_ trusted_db_delete] 3 flow_in ?? runtime value 4..9 bdaddr[] nap[0,1]:uap[2]:lap[3,4,5] bluetooth addr of device to be unpaired
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 72 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 response packet offset field value comments 0 length 11 fixed 1 channel 0 fixed 2 command [cmd_ trusted_db_delete] 3 flow_out ?? runtime value 4 status as appropriate 5..10 bdaddr[] nap[0,1]:uap[2]:lap[3,4,5] bluetooth addr, echoed from the command 3.15.9 trusted database change type this command transfer s a record to the database specified. command packet offset field value comments 0 length 11 fixed 1 channel 0 fixed 2 command [cmd_trusted_db_changetype] 3 flow_in ?? runtime value 4 dbtype 0..1 5..10 bdaddr[] nap[0,1]:uap[2]:lap[3,4,5] bluetooth addr response packet offset field value comments 0 length 12 fixed 1 channel 0 fixed 2 command [cmd_trusted_db_changetype] 3 flow_out ?? runtime value 4 status as appropriate 5 dbtype 0..1 echoed from command 6..11 bdaddr[] nap[0,1]:uap[2]:lap[3,4,5] bluetooth addr, echoed from command 3.15.10 trusted database is peer trusted this command check s if a device is trusted. command packet offset field value comments 0 length 10 fixed 1 channel 0 fixed 2 command [cmd_ trusted_db_istrusted] 3 flow_in ?? runtime value 4..9 bdaddr[] nap[0,1]:uap[2]:lap[3,4,5] bluetooth addr
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 73 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 response packet offset field value comments 0 length 11 fixed 1 channel 0 fixed 2 command [cmd_ trusted_db_istrusted] 3 flow_out ?? runtime value 4 status as appropriate 5..10 bdaddr[] nap[0,1]:uap[2]:lap[3,4,5] bluetooth addr, echoed from the command the status value is mpsta tus_ok if the device is trusted; any other value means not trusted. if s reg 47 is set to one , then if the peer device is found in the trusted device database, then the event evt_link_key_ex is sent to the host before the response. that event contains the address and link key associated with that address. 3.15.11 trusted database add key (out - of - band facilitator) this command manually add s a link key /address pair into the rolling trusted database. the module does not care how the key was generated and the only validation it performs is to check that it is 16 bytes long. command packet offset field value comments 0 length 1e fixed 1 channel 0 fixed 2 command [cmd_trusted_db_add] 3 flow_in ?? runtime value 4..9 bdaddr[6] nap[0,1]:uap[2]:lap[3,4,5] bluetooth addr 10..25 key[16] 16 byte link key any random value 26..29 flags[4] 05 00 00 00 for future use and must be set to 0 5 000000 response packet offset field value comments 0 length 11 fixed 1 channel 0 fixed 2 command [cmd_ trusted_db_add] 3 flow_out ?? runtime value 4 status as appropriate the status value is mpstatus_ok if the device was successfully added to the database. if the device bluetooth address is already in the trusted device database, then the old one is deleted and is replaced by this new one.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 74 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 3.16 miscellaneous commands 3.16.1 get security mode this command get s the current security mode of the module. bluetooth v2.1 and newer de vices cannot disable security t herefore only values 12 to 15 inclusive are valid. these values specify simple secure pairing with appropriate i/o capabilities. specifying a value of 0xff mean s leave the mode as it is, but inform the host with regards to current mode. command packet offset field value comments 0 length 5 fixed 1 channel 0 fixed 2 command [cmd_security_mode] 3 flow_in ?? runtime value 4 secmode 0xff 0xff = get current mode response packet offset field value comments 0 length 6 fixed 1 channel 0 fixed 2 command [cmd_security_mode] 3 flow_out ?? runtime value 4 status as appropriate 5 secmode 12..15 current mode 12 = ssp with no input no output 13 = ssp with yes/no display 14 = ssp with keyboard only 15 = ssp with display only secmode is now driven by the simple secure pairing procedure included in and after v2.1 of the bluetooth specification for secmode the no i/o capability option is equivalent to just works scenario in simple secure pairing. when this module interacts with a pre 2.1 device it is unconditionally forced into legacy pairing mode. t he reader sh ould become familiar with the simple secure p airing concept introduced in and all subsequent version of bluetooth after v2.1. the best introduction is to google the phrase bluetooth s im ple secure p airing. the reader is also welcome to contact la ird for an informal discussion. 3.16.2 get remote friendly name this command get s the friendly name of the specified peer device. according to the bluetooth specification , a friendly name can be up to 248 bytes long. sending this name in its entirety to the host could violate the max pack et length capability of the host because me mory restrictions in the host or transmit buffers in the module may not be able to cope. therefore, the mechanism for getting the name to the host is via multiple event packets is evt_rem_fname. the host decides h ow many bytes of the name are passed up to it via these events from the offset it also specifies. this implies that in a memory constraint environment, it is possible to relay the name to the host using multiple commands. for example, if the host has space for only 10 bytes and a peer happens to have a very long name, the host can ask for 10 byte fragments of the name over multiple get name requests. command packet
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 75 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 offset field value comments 0 length 13 fixed 1 channel 0 fixed 2 command [cmd_get_rem_fname] 3 flow_in ?? runtime value 4..9 bdaddr[] nap[0,1]:uap[2]:lap[3,4,5] bluetooth addr 10 timeout 2..120 timeout in seconds 11 start n offset into the friendly name string 12 maxbytes m max imum number of characters to read response packet offset field value comments 0 length 8 fixed 1 channel 0 fixed 2 command [cmd_get_rem_fname] 3 flow_out ?? runtime value 4 status as appropriate 5 namelen 0..248 actual size of the friendly name 6 start n echoed from the command 7 sentlen s total number of bytes sent note: sentlen could be less than maxbytes. it can happen if there is no space in the modules tx buffer to send events. figure 3 - 16 : get remote friendly name sequence diagram host module req friendly name evt_rem_fname (index=0,len=10,"?????") cmd_rem_fname (bdaddr, timeout, start=0, maxbytes=25) evt_rem_fname (index=10,len=10,"?????") evt_rem_fname (index=20,len=5,"?????") got friendly name (47 bytes) cmd_rem_fname (namelen=47,start=0,sent=25) cmd_rem_fname (bdaddr, timeout, start=25, maxbytes=22) req friendly name got friendly name (47 bytes) evt_rem_fname (index=25,len=10,"?????") evt_rem_fname (index=35,len=10,"?????") evt_rem_fname (index=45,len=2,"?????") cmd_rem_fname (namelen=47,start=25,sent=22)
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 76 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 3.16.3 get local friendly name this command read s the local friendly name which is s tored in non - volatile memory. unlike remote friendly name (with no control over the max . l ength ) the max . local friendly name is 31 char acter s. this length may still be too big to send to the host in one pa cket. therefore it is s ent in a similar fashion to get friendly name described above. i n this case, the event evt_lcl_fname get s the name to the host. command packet offset field value comments 0 length 6 fixed 1 channel 0 fixed 2 command [cmd_get_lcl_fname] 3 flow_in ?? runtime value 4 start n offset into the friendly name string 5 maxbytes m max imum number of characters to read response packet offset field value comments 0 length fixed 1 channel 0 fixed 2 command [cmd_get_lcl_fname] 3 flow_out ?? runtime value 4 status as appropriate 5 namelen 0..31 actual size of the friendly name 6 start n echoed from the command 7 sentlen s total number of bytes sent in preceding events. the name string is s ent to the host in evt_lcl_fname packets. see description of get remote friendly name note: sentlen could be less than maxbytes. it can happen if there is no space in the modules tx buffer to send events. 3.16.4 set local friendly name this command set s the local friendly name in non - volatile memory so that it is used after a power up/reset cycle. since the module can cope with large packets, the name is sent to the module in a single command packet as a null terminated string. command packet offset field value comments 0 length 37 fixed 1 channel 0 fixed 2 command [cmd_set_lcl_fname ] 3 flow_in ?? runtime value 4 flags 1..2 1 = write to non - vol store for use on next power up
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 77 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 command packet offset field value comments 2 = make the name visible now 5 namelen 1..30 6..36 name[31] null terminated string not more than 30 characters response packet offset field value comments 0 length 5 fixed 1 channel 0 fixed 2 command [cmd_set_lcl_fname] 3 flow_out ?? runtime value 4 status as appropriate 3.16.5 set device class this command set s the device class code so that the base band makes it visible immediately. this is opposed to setting it via s register 120 w hich only expedites on power up. command packet offset field value comments 0 length 7 fixed 1 channel 0 fixed 2 command [cmd_set_devclass] 3 flow_in ?? runtime value 4..6 devclass[3] new 24 bit device class msb of device class is at offset 4 response packet offset field value comments 0 length fixed 1 channel 0 fixed 2 command [cmd_set_devclass] 3 flow_out ?? runtime value 4 status as appropriate 3.16.6 factory default this command clear s non - volatile memory in the module so that it reverts to factory default state. the flags field is a bit mask which selectively clear s various types of non - volatile memory and should be set to ff. command packet offset field value comments 0 length 5 fixed 1 channel 0 fixed
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 78 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 2 command [cmd_factorydefault] 3 flow_in ?? runtime value 5 flags 8 bit mask see notes below 0xff to delete all groups, present and future response packet offset field value comments 0 length fixed 1 channel 0 fixed 2 command [cmd_factorydefault] 3 flow_out ?? runtime value 4 status as appropriate note : non - volatile information in the module is divided into various subgroups and the flags bits allow selective resetting to factory state for those subgroups. the bits are allocated as follo ws: bit 0 : s registers bit 1 : local friendly name bit 2 : hid device descripto r s bit 3 : reserved C always set to 1 bit 4 : reserved C always set to 1 bit 5 : reserved C always set to 1 bit 6 : link keys bit 7 : special s registers (240 to 255 in the multipoint space) 3.16.7 get digital/analog i/o this command read s the states of up to 16 digital input lines and optionally request s an analogue input reading. this response packet contains two octets containing the digital input states. if an analogue input reading is requested then the adc reading is supplied in an event_adc event. command packet offset field value comments 0 length 6 fixed 1 channel 0 fixed 2 command [cmd_get_io] 3 flow_in ?? runtime value 4 digid 0 0 = digital i/o in module 5 analogid 0 0 = no adc access 1 = aio0 2 = aio1 3 ..255 = future use ( see note 1 ) response packet offset field value comments
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 79 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 0 length fixed 1 channel 0 fixed 2 command [cmd_get_io] 3 flow_out ?? runtime value 4 status as appropriate 5 digid 0 echoed from command packet 6..7 digin[2] ?? digital inputs 0 to 15. bit 15 is bit 7 in the msb. ( see note 2 ) note 1: if the analo gid field in the command is non - zero and a valid value , then an event_adc is generate d when the adc is read . note 2: bit 0 corresponds to gpio0, bit 1 corresponds to gpio1, etc. refer to the modules data sheet to check which gpio pins are available for use. 3.16.8 set digital i/o this command control s the states of up to 16 digital output lines. command packet offset field value comments 0 length 6 fixed 1 channel 0 fixed 2 command [cmd_set_io_ex] 3 flow_in ?? runtime value 4 ioid 0 0 = digital i/o in module 5..6 mask[2] 0000..ffff only set bits s pecify which bits in ioval submit to the digital i/o ( see note 1 ) 7..8 ioval[2] 0000..ffff only the bits set in mask update at the output . ( see note 1 ) response packet offset field value comments 0 length fixed 1 channel 0 fixed 2 command [cmd_set_io] 3 flow_out ?? runtime value 4 status as appropriate bit 0 corresponds to gpio0, bit 1 to gpio1 etc. please refer to the modules data sheet to check which gpio pins are available for use. 3.16.9 reset this command reset s the module. command packet offset field value comments 0 length 7 fixed 1 channel 0 fixed 2 command [cmd_reset]
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 80 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 3 flow_in ?? runtime value 4..6 resvd[3] 00 00 00 reserved for future use, set to zeros. there is no response to this command packet. however, on reset there is at least one evt_status event , so that can be used to detect that the device has rebooted. 3.16.10 blob manage this command manage s binary data uploaded from the host through data channels 0x98 to 0x9f (the number of blob data channels is compile time dependent). the binary data is referred to as a blob ( b inary l ong ob ject). command packet offset field value comments 0 length 14 fixed 1 channel 0 fixed 2 command [cmd_blobmanage] 3 flow_in ?? runtime value 4 subcmdid 0..9 5 blobid 0..1 identifies the blob that this command acts on. data channels correspond to (0x98 + blobid ) 6..9 parma offset 6 is msb offset 9 is lsb parameter a 10..13 parmb offset 10 is msb offset 13 is lsb parameter b response packet offset field value comments 0 length 15 fixed 1 channel 0 fixed 2 command [cmd_ blobmanage] 3 flow_out ?? runtime value 4 status as appropriate 5 subcmdid echoed from command 6 blobid echoed from command 7..10 parma offset 7 is msb offset 10 is lsb depends on subcmdid 11..14 parmb offset 11 is msb offset 14 is lsb depends on subcmdid action to perform
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 81 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 subcmdid field specifies the action s that the blob manager should take on the blob specified in field blobid and are described in the following sub sections. clear :: 0 use this subcommand to clear the blob specified by blobid , on return parma and parmb are set to zero . get size :: 1 use this subcommand to get the number of bytes in the blob specified by blobid , on return parma contains the number and parmb is set to zero . read :: 2 use this subcommand to transmit the content of the blob specified by b lobid . if there is data in the blob then it result s in one or more data packets being s ent to the host on channel (0x98+blobid ).the data in the blob is not destroyed. on return parma contains the number of bytes in the blob and parmb contains the number actually sent in the data packets. save hid descriptor :: 3 use this subcommand to first do a basic validation of the data block identified by blobid to see that it contains a valid hid descriptor and if so, save the data to a non - volatile memory set aside to save an array of hid descriptors. the index into that array is specified by parma which is referred to as the hidid. in the response, parma contains 0 for success, 1 for invalid hid descriptor, 2 for failed to save to non vol array and 000000ff for invalid blobid or invalid hidid . load hid descriptor :: 4 use this subcommand to append the content of the hid descriptor in non - volatile memory identified by a hidid which is specified in parma into the data object identified by blobid . in the response, parma contains 0 for success, 2 for failed to load from nonvol array and 000000ff for invalid blobid or invalid hidid . after the blob loads , use subcommand read::2 to force the transmission of the hid descriptor to the host. save custom hid descriptor service name :: 5 use this subcommand to save the service name (less than 30 characters) that is used when a custom hid device sdp record is registered (when sreg 39 > 0). in the response, parma contains 0 for success, 1 for invalid s ervice na me, 2 for failed to save to nonvol array and 000000ff for invalid blobid . load custom hid descriptor service name :: 6 use this subcommand to append the content of the hid service name in non - volatile memory. in the response, parma contains 0 for success, 2 for failed to load from nonvol array and 000000ff for invalid blobid . after the blob loads , use subcommand read::2 to force the transmission of the name to the host. commit blob as enhanced inquiry :: 7 use this subcommand to commit the current content of the blob specified as enhanced inquiry responses. the data validates so that it conforms to the format specified in described in the bluetooth specification version 2.1 + edr [1], vol3, part c C generic access profile, 8 extended inquiry response data format (page 1305 in the .pdf - file). t he data block consists of one or more objects, where the first byte of each object specifies the length and the second byte specifies the type of data and the rest of th e bytes for that object are the associated data. for example, to send the string helloworld and lairdrules! as the manufacturer specific data objects, then the blob should load with the fo llowing data :
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 82 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 0b ff h e l l o w o r l d 0c ff l a i r d r u l e s ! where 0b and 0c are length bytes and ff is the type value for manufacturer specific data . before submission, the data block is verified to see if the length bytes are consistent with total length of the bloc k. save enhanced inquired response data :: 8 use this subcommand to save the blob data in non - volatile memory so that the data install s the custom eir data response on every power up. before committing to memory, the data block is verified to see if the le ngth bytes are consistent with total length of the block. load enhanced inquired response data:: 9 use this subcommand to load the blob specified with data from non - volatile memory associated with enhance d inquiry responses; t he data that was saved using subcommand 8 described above . 3.17 hdp profile commands health device profile (hdp) is available on the module in both agent and manager roles as defined by the continua alliance (see www.cont inua.org ). the manager role is for testing the agent implementation only and it is not expected or designed for eventual certification by the continua alliance . it is assumed that the reader is familiar with all the hdp and ieee documentation and relevant guidelines publ ished by the continua alliance. for further background information related to the hdp implementation in this module please ref er to at application examples . the hdp commands, responses and events described in the subsequent chapters are merely the mp way of man aging the functionality and do not add any new features other than those described in the at applications example section. laird recommends the reader t o refer to the at application examples section for further details. to assist with this cross referencing of details, the table below shows the equivalent commands in at and mp mode respectively to achieve the same effect in the module. at mode comman ds mp mode commands comments at+haeiiii,name at+hmeiiii,name eeeeee at+harhhhh,pppp[]
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 83 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 the following table shows the equivalent at asynchronous responses and mp events. at mode async responses mp mode events comments hda:disassociated hhhh hdm:disassociated hhhh evt_hdp_disassociated sent to host when the agent disassociates from the manager or fails to connect to it hda:associated hhhh,.. hdm:associated hhhh,.. evt_hdp_associated hda:time hhhh,ttttt evt_hdp_timeupdate at agent end only. manager informs agent host of new date/time . manager triggers this using the command at+hmd or cmd_hdp_settime 3.17.1 hdp related s registers to enable hdp profile, bit 2 i n sreg 3 must be set to one and sreg 70 specifies wh ether it is an agent role ( = 0 ) or a manager role ( = 1 ). in addition sreg 71 specifies the auto - disassociate timeout in the agent role only, where 0 denote s no timeout. if this is a non - zero value, the n after an association or the triggering of a scan report if no further activity occurs in that time, then an automatic disassociation initiates . sreg 72 specifies the maximum transmit pdu size for hdp packets in the underlying bluetooth transport layer . 3.17.2 c reate endpoint in sdp record this command create s a data specialization source (for agent role) or a sink ( for manager role) which registers using the cmd_hdp_sdpregister command. this sdp entry allow s peers to determi ne which data specialization the module services . it is not necessary to specify which role explicitly in the command because s reg 70 determine s whether the module is configured for an agent or manager role. for agent role sreg 70 is set to 0 and 1 for ma nager. this command is relevant for both agent and manager roles. command packet offset field value comments 0 length 22 fixed 1 channel 0 fixed 2 command [cmd_hdp_endpoint] 3 flow_in ?? runtime value 4..5 spectype[2] as per ieee spec [4]=msb,[5]=lsb data specialization code. for example: 100f (4111 dec) for weigh scale 6..21 name[15+1] null terminated name max . name size is 15 . must be terminated by a null response packet offset field value comments 0 length 5 fixed 1 channel 0 fixed
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 84 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 2 command [cmd_hdp_endpoint] 3 flow_out ?? runtime value 4 status as appropriate create m ultiple data specialization endpoints by submitting this command an appropriate number of times. internally in the module, the spectype[ 2] and name[15+1] information caches in heap memory until the command cmd_hdp_sdpregister transfers that information into the sdp record for final submission to the underlying bluetooth stack. 3.17.3 register sdp record this command register s and activa te s a n hdp related sdp record after creating the endpoint s using cmd_hdp_endpoint. only after this is done can incoming hdp connections be serviced. it is not necessary to specify which role explicitly in the command because s reg 70 determine s whether the module is configured for an agent or manager role. for agent role sreg 70 is set to 0 and 1 for manager. this command is relevant for both agent and manager roles. command packet offset field value comments 0 length 4 fixed 1 channel 0 fixed 2 command [cmd_hdp_sdpregister] 3 flow_in ?? runtime value response packet offset field value comments 0 length 5 fixed 1 channel 0 fixed 2 command [cmd_hdp_sdppregister] 3 flow_out ?? runtime value 4 status as appropriate internally in the module, the spectype[2] and name[15+1] information previously cached in heap memory from cmd_hdpendpoint commands transfers into a n sdp record a nd submits to the underlying stack. after this a peer is able to see this device offering hdp services. 3.17.4 bind agent to a manager this command bind s the bluetooth address of a manager and an agent data specialization to create an object within the module which a 16 bit handle ca n subsequently reference, which returns i n the resp onse if the command successfully accepts . this command is relevant for agent role only. command packet offset field value comments 0 length 14 fixed 1 channel 0 fixed 2 command [cmd_hdp_bind]
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 85 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 command packet offset field value comments 3 flow_in ?? runtime value 4..9 bdaddr[] nap[0,1]:uap[2]:lap[ 3,4,5] bluetooth address 10.11 spectype[2] as per ieee spec [10]=msb,[11]=lsb data specialization code. for example: 100f (4111 dec) for weigh scale 12.13 assoctout[2] [12]=msb,[13]=lsb automatic deassociation timeout. 0 = no timeout response packet offset field value comments 0 length 7 fixed 1 channel 0 fixed 2 command [cmd_hdp_bind] 3 flow_out ?? runtime value 4 status as appropriate 5..6 handle[2] [5]=msb,[6]=lsb handle id entifying this instance of data specialization agent the handle returned in the response, if status equals 0, is subsequently used in many commands. if the status byte is not 0, then the handle value i 0. 3.17.5 associate with manager this command associate s an agent with a manager, using the pre - defined object created using the cmd_hdp_bind command which returns a handle to represent that object. this command is relevant for agent role only. command packet offset field value comments 0 length 6 fixed 1 channel 0 fixed 2 command [cmd_hdp_associate] 3 flow_in ?? runtime value 4..5 handle[2] [4]=msb,[5]=lsb handle identifying an instance of data specialization agent/manager combination response packet offset field value comments 0 length 5 fixed 1 channel 0 fixed 2 command [cmd_hdp_associate] 3 flow_out ?? runtime value 4 status as appropriate
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 86 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 the host wait s until the respons e receives before submitting further commands. if association is successful prior to receiving the response, the host sends evt_associated, which contain s the config id of the mds configuration that was negotiated and the system id of the peer. see evt_associated for further details. if association was not successful, because for example the manager is not in range or th e bluetooth device specified in cmd_hdp_bind does not offer hdp servic es, then the evt_disassociated sends to the host prior to the response message. this is shown in the message sequence diagram below. figure 3 - 17 : associate sequence diagram 3.17.6 send fixed scan report to manager this command associate s (if not already associated) and send s a fixed scan report from an agent to the bound manager. t he binding specified via the cmd_hdp_bind command which returns a handle to represent that combination object. this command is relevan t for agent role only, and result s in a n evt_hdp_scanreport event at the manager end. a fixed report sends the values for a list of attributes to a manager where the list is predefined in the mdc_attr_attribute_val_map attribute of the nu collection object. command packet offset field value comments 0 length 9 fixed 1 channel 0 fixed 2 command [cmd_hdp_scanreport_fixed] 3 flow_in ?? runtime value 4..5 handle[2] [4]=msb,[5]=lsb handle identifying an instance of data specialization agent/manager combination 6..7 personid[2] [6]=msb,[7]=lsb this identifies a person id which the manager can uses appropriately 8 hostcontext xx this echos back in the response and helps the host to keep track of cmd_hdp_associate(handle) evt_associated(handle,spec,cfgid,sysid) rsp_hdp_associate(ok) agent host cmd_hdp_associate(handle) evt_disassociated(handle) rsp_hdp_associate(not ok) agent host successful association unsuccessful association
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 87 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 them response packet offset field value comments 0 length 8 fixed 1 channel 0 fixed 2 command [cmd_hdp_scanreport_fixed] 3 flow_out ?? runtime value 4 status as appropriate 5..6 handle[2] [4]=msb,[5]=lsb echoed back from the command 7 hostcontext xx this is echoed back from the command the host wait s until the response receives before submit t ing further commands. if the agent is not as sociated, then this command first result s in an association request and if that is successful the host receives evt_associated which contain s the config id of the mds configuration that was negotiated and the system id of the peer. see evt_associated for further details. if t he agent is already associated, then there is a response as soon as there is acknowledgement from the manager that the scan report was received. if association was not successful, because for example the manager is not in range or the bluetooth device specified in cmd_hdp_bind does not offer hdp services, then the evt_disassociated sends to the host prior to the response message. this is shown in t he message sequence diagram below ( figure 3 - 18 ) .
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 88 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 3.17.7 message sequence c hart for fixed scan report figure 3 - 18 : fixed scan report sequence diagram host agent no prior association and successful scan report evt_associated(handle,spec,cfgid,sysid) host agent cmd_hdp_scanreport_fixed(handle,personid,ctx) prior association and successful scan report host agent cmd_hdp_scanreport_fixed(handle,personid,ctx) evt_disassociated(handle) no prior association and unsuccessful scan report host agent cmd_hdp_scanreport_fixed(handle,personid,ctx) prior association and unsuccessful scan report cmd_hdp_scanreport_fixed(handle,personid,ctx) rsp_hdp_scanreport_fixed(ok) rsp_hdp_scanreport_fixed(ok) rsp_hdp_scanreport_fixed(not ok) rsp_hdp_scanreport_fixed(not ok)
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 89 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 3.17.8 send var scan report to manager this command associate s (if not already associated) and then send s a var scan report from an a gent to the bound ma nager; the binding is specified via the cmd_hdp_bind command which returns a handle to represent that combination. this command is relevant for agent role only, and result s in a n evt_hdp_scanreport event at the manager end. a var report sends the values for a list of attributes in the nu collection object to a manager where the host pre - supplies the list . if an attribute does not exist in the nu collection then it is silently ignored. the list is provided by the host via the blob data channel for the blob id specified in the command (that is, channel number 0x98 plus blobid). command packet offset field value comments 0 length 10 fixed 1 channel 0 fixed 2 command [cmd_hdp_scanreport_var] 3 flow_in ?? runtime value 4..5 handle[2] [4]=msb,[5]=lsb handle identifying an instance of data specialization agent/manager combination 6..7 personid[2] [6]=msb,[7]=lsb this identifies a pers on id which the manager can use appropriately 8 hostcontext xx this echoes back in the response and helps the host to keep track of them 9 blobid 0..n see section blob manage for details of response packet offset field value comments 0 length 8 fixed 1 channel 0 fixed 2 command [cmd_hdp_scanreport_var] 3 flow_out ?? runtime value 4 status as appropriate 5..6 handle[2] [4]=msb,[5]=lsb echoed back from the command 7 hostcontext xx this echoes back from the command the host wait s until the response re ceives before submi t ting further commands. if the agent is not associated, then this command first result s in an association request and if that is successful the host sends evt_associated which contain s the config id of the mds configuration that was negotiated and the system id of the peer. see evt_associated for further details.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 90 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 if the agent is already associated, then there is a response as soon as the manager acknowledges that the scan report was received. if association was not successful, because for examp le the manager is not in range or the bluetooth device specified in cmd_hdp_bind does not offer hdp services, then the evt_disassociated sends to the host prior to the response message. this is shown in the message sequence diagram below ( figure 3 - 19 ) . 3.17.9 message sequence chart for var scan report figure 3 - 19 : var scan report sequence diagram host agent cmd_hdp_scanreport_var(handle,personid,ctx,blobid) data channel[0x98+blobid] {aaaa,bbbb,cccc ....} no prior association and successful scan report data removed from blob data channel rsp_hdp_scanreport_var(ok) evt_associated(handle,spec,cfgid,sysid) host agent cmd_hdp_scanreport_var(handle,personid,ctx,blobid) data channel[0x98+blobid] {aaaa,bbbb,cccc ....} data removed from blob data channel prior association and successful scan report rsp_hdp_scanreport_var(ok) host agent cmd_hdp_scanreport_var(handle,personid,ctx,blobid) data channel[0x98+blobid] {aaaa,bbbb,cccc ....} data removed from blob data channel no prior association and unsuccessful scan report rsp_hdp_scanreport_var( not ok) evt_disassociated(handle) host agent cmd_hdp_scanreport_var(handle,personid,ctx,blobid) data channel[0x98+blobid] {aaaa,bbbb,cccc ....} data removed from blob data channel rsp_hdp_scanreport_var( not ok) prior association and unsuccessful scan report
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 91 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 3.17.10 read attribute value this command is valid for b oth agent and manager role and read s the value of the attribute specified via the attribute id and the qualifier id. the value returns in hdp data channel 0xb0 formatted as described below. command packet offset field value comments 0 length 10 fixed 1 channel 0 fixed 2 command [cmd_hdp_attribute_read] 3 flow_in ?? runtime value 4..5 handle[2] [4]=msb,[5]=lsb handle identifying an instance of data specialization agent/manager combination 6..7 attrid[2] [6]=msb,[7]=lsb 8..9 qualifierid[2] [8]=msb,[9]=lsb see note 1 response packet offset field value comments 0 length 8 fixed 1 channel 0 fixed 2 command [cmd_hdp_attribute_read] 3 flow_out ?? runtime value 4 status as appropriate 5 hostcontext xx this is echoed back from the command 6..7 handle[2] [6]=msb,[7]=lsb echoed back from the command for manager role , this is the object id (mds=0,nu=1 etc) and for agent please refer to section weigh scale data specialization. as more data specializations are added, the qualifierid specifies appropriately for that specialization. the host shall wait until the respons e receives before submiting further commands. if the attribute exists, then the data sends in a logical hdp data packet transported in one or more physical data packets over channel 0xb0. the physical packets of incoming data in channel 0xb0 is viewed as a stream of data making up logical packets. t he logical packet format is as follows and is also addresse d in a dedicated section later: len[2],00,handle[2],attrid[2],qualifierid[2],data[n] where len[2], handle[2],attrid[2],qualifierid[2] are in big endian format (msb sent first) and n is equal to len[2]+9. the 00 after the len[2] field signifies that this logical packet consists of attribute data. since all data is transparently treated in t he module, the e ndian of data[n] should be determined by trial and error with the aid of a n hdp manager and finalized to be correct by the time the implementation submits for certification by the continua alliance. however, if the attribute data type is a 16 or 32 bit integer/float, then it is little endian.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 92 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 3.17.11 w rite attribute value this command is valid for agent role only and write s the value of the attribute, already preloaded in hdp data channel 0xb0, where the attribute id a nd the qualifierid is supplied in the command packet. command packet offset field value comments 0 length 10 fixed 1 channel 0 fixed 2 command [cmd_hdp_attribute_write] 3 flow_in ?? runtime value 4..5 handle[2] [4]=msb,[5]=lsb handle identifying an instance of data specialization agent/manager combination 6..7 attrid[2] [6]=msb,[7]=lsb 8..9 qualifierid[2] [8]=msb,[9]=lsb see note 1 response packet offset field value comments 0 length 8 fixed 1 channel 0 fixed 2 command [cmd_hdp_attribute_write] 3 flow_out ?? runtime value 4 status as appropriate 5 hostcontext xx this echoes back from the command 6..7 handle[2] [6]=msb,[7]=lsb echoes back from the command for manager role , this i s the object id (mds=0,nu=1 etc) . as more data specializations are added, the qualifierid specifies appropriately for that specialization. the host wait s until the response receives before submiting further commands. if the attribute exists, then the data moves from chan nel 0xb0 to the attribute container variable. if the attribute does not exist, then the data discards . all the data in the channel is treated as the data for the attribute; that is, there is no qualifying information affixed to the data. in ad dition, if th e attribute exists but the data length does not match that of the attribute, then the write fail s (with an appropriate error code) and the data in the channel is discarded. since all data is transparently treated in the module, the e ndian of data[n] should be determined by trial and error with the aid of a hdp manager and finalized to be correct by the time the implementation is submitted for certification by the continua alliance. however, if the attribute data type is a 16 or 32 bit integer/float, then it will be little endian. 3.17.12 set date and time this command is valid for manager role only and update s the date and time in the associated agent identified by the handle. when any hdp manager sends a time update to an agent, it result s in an evt_hdp_update event to the host of that agent. command packet
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 93 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 offset field value comments 0 length 14 fixed 1 channel 0 fixed 2 command [cmd_hdp_set_time] 3 flow_in ?? runtime value 4..5 handle[2] [4]=msb,[5]=lsb handle identifying an instance of data specialization agent/manager combination 6..13 datetime[8] ccyymmddhhssnnxx see note 1 response packet offset field value comments 0 length 14 fixed 1 channel 0 fixed 2 command [cmd_hdp_set_time] 3 flow_out ?? runtime value 4 status as appropriate this command supplies t he date/time information as a string of 8 bytes ccyymmddhhssnnxx where each byte is as follows: cc century e.g for 2011 the value shall be 0x14 yy year e.g for 2011 the value shall be 0x0b mm month e.g for january the value shall be 0x01 and for say december 0x0c dd day e.g for 31 the value shall be 0x1f (0 is illegal value) hh hour e.g for 6:45pm the value shall be 0x12 nn minutes e.g for 6:45pm the value shall be 0x2d xx fraction this is a fraction of a seconds in hundred ths of unit. valid 00..0x63 (99 for example the date and time 2 feb 2011, 16:43:33.78 sends at the string 150c020c102d214e the host wait s until the response receives before subm itting further commands. 3.17.13 disassociate from manager this command disassociate s an agent identified by the handle specified in the command from a manager. this command is relevant for agent role only. command packet offset field value comments 0 length 6 fixed 1 channel 0 fixed 2 command [cmd_hdp_disassociate] 3 flow_in ?? runtime value 4..5 handle[2] [4]=msb,[5]=lsb handle identifying an instance of data specialization agent/manager combination response packet
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 94 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 offset field value comments 0 length 5 fixed 1 channel 0 fixed 2 command [cmd_hdp_disassociate] 3 flow_out ?? runtime value 4 status as appropriate the host wait s until the response receives before submitting further commands. the response sends immediately after initiating the disassociation and when the procedure is complete , an evt_disassociated is sent to the host as shown in the message sequence diagram below ( figure 3 - 20 ) . figure 3 - 20 : disassociate sequence diagram agent host rsp_hdp_disassociate(ok) cmd_hdp_disassociate(handle) evt_disassociated(handle)
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 95 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 4 m odule e vents this section describes all module origi nated asynchronous events in detail and is specified via the evt_id field of all event packets. the description for each event below is in the form of an event packet tables. each event has a unique evt_id value in the range 129 to 255 (0x81 to 0xff), 0x80 is reserved. the actual value of evt_id in the value column is d escribed as [descriptive_name] where descriptive_name ca n be found in a c header file, obtained on request from laird. 4.1 inquiry events this group of events is inquiry related. 4.1.1 inquiry result this event send s the inquiry response from a peer as a result of an inquiry request. event packet offset field value comments 0 length 13 1 channel 0 2 event [evt_ inquiry_result] 3 flow_out ?? runtime value 4..9 bdaddr[6] nap[0,1]:uap[2]:lap[3,4,5] bluetooth address of responding device 10..12 devclass[3] 0x000000 .. 0xffffff device class of responding device 4.2 information events this group of events convey s information about the module, for example to status. 4.2.1 unknown command this event inform s the host that a received command had an unknown com mand value. the command value echoe s in offset 4. event packet offset field value comments 0 length 1 channel 2 event [evt_unknown_command] 3 flow_out ?? runtime value 4 command xx cmd_id value echoed from command
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 96 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 4.2.2 status this event asynchronously send s current status to the host. this event is sent to the host after power up to inform the host that the mo dule is ready and operational. you can also obtain t he information contained in this message by sending the cmd_get_modes command. event packet offset field value comments 0 length 8 1 channel 0 2 event [evt_ status] 3 flow_out ?? runtime value 4 status ok or invalid_license 5 discmode 0..1 1 for discoverable mode 6 connmode 0..1 bit 0: 1 for connectable mode in future bit 1, if set, may indicate that incoming spp connections are auto accepted 7 secmode 12..15 12 = ssp + io_cap_no_input_no_output 13 = ssp + io_cap_display_yes_no 14 = ssp + io_cap_keyboard_only 15 = ssp + io_cap_display_only 4.2.3 invalid packet size this event inform s the host that a command packet was received whose length does not match the size of the struct ure published in the interface header file bmhostprotocol.h. event packet offset field value comments 0 length 7 1 channel 0 2 event [evt_invalid_pktsize] 3 flow_out ?? runtime value 4 cmd_id 1..127 echoed from the command 5 act_size a actual size of the packet 6 des_size d desired size of the packet 4.3 connection events this group of events are connection related.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 97 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 4.3.1 connection setup this event inform s the host that a remote device is requesting a connection. the host respond s with a cmd_connection_setup with an accept or reject flag. event packet offset field value comments 0 length 12 1 channel 0 2 event [evt_ connection_setup] 3 flow_out ?? runtime value 4..9 bdaddr[6] nap[0,1]:uap[2]:lap[3,4,5] bt address of device requesting connection 10..11 uuid[] server profile uuid the peer wishes to connect to 0x1101 = spp 0x1124 = hid device t he uuid field tells the host which server profile the peer wishes to connect to. 4.3.2 incoming connection this event inform s the host that an incoming connection established. event packet offset field value comments 0 length 13 1 channel 0 2 event [evt_ connection_setup] 3 flow_out ?? runtime value 4 channel 1..254 channel id to be used to send/receive data, see n ote 1 for channel number allocation. 5..10 bdaddr[6] nap[0,1]:uap[2]:lap[3,4,5] bluetooth address of device requesting connection 11..12 uuid[] server profile uuid the peer wishes to connect to 0x1101 = spp 0x1124 = hid device the uuid field tells the host which server profile the peer has connected to. channel n umber allocation is as follows: profile channel id range command parser 0x00 spp 0x1 .. 0x7 hid device(canned) 0x20 hid host(raw) 0x90 .. 0x97 hid device(raw) 0xa0 blob 0x98 .. 0x9f hdp 0xb0..0xb1 (b1 is continuation channel) enhanced inquiry response 0xf0
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 98 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 4.3.3 disconnect this event inform s the host that a connection was dropped by the remote device. event packet offset field value comments 0 length 6 1 channel 0 2 event [evt_ disconnect] 3 flow_out ?? runtime value 4 channel 1..7 channel number 5 reason 0..255 as per the table below the bluetooth specification specifies the reason value . please note that values in the range 0xf0 to 0xff are custom values defined for this implementation and do not appear in the bluetooth specification. 0x010x3f 4.3.4 modem status this event convey s modem status signals originating from the peer device for an spp connection. event packet offset field value comments 0 length 6 1 channel 0 2 event [evt_ modem_status] 3 flow_out ?? runtime value 4 channel 1..7 channel id of an open spp channel 5 modemsig bit mask bit 0: dsr state bit 1: cts state bit 2: dcd state bit 3: ri state 6 breaksig 0 for future implementation 4.4 miscellaneous events 4.4.1 link key this event inform s the host that a new link key was created for the device indicated and the result of writing to the rolling database. event packet
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 99 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 offset field value comments 0 length 11 1 channel 0 2 event [evt_ link_key] 3 flow_out ?? runtime value 4..9 bdaddr[6] nap[0,1]:uap[2]:lap[3,4,5] bluetooth address of paired device 10 dbresult 0: success any other value is a failure and the reason is a status value as per mpstatus.h 4.4.2 link key ex this event is s ent to the host when cmd_trusted_db_istrusted processes, a link key for that peer device exists , and s register 47 is set to 1. it convey s the link key along with the bluetooth address to the host . event packet offset field value comments 0 length 30 1 channel 0 2 event [evt_ link_key_ex] 3 flow_out ?? runtime value 4..9 bdaddr[6] nap[0,1]:uap[2]:lap[3,4,5] bluetooth address of paired device 10..25 key[16] 16 byte array the link key 26..29 rfu[4] 4 byte array reserved for future 4.4.3 pin code request this event inform s the host that a remote device requested a pairing and the procedure requires a pin code to complete. event packet offset field value comments 0 length 10 1 channel 0 2 event [evt_ pincode_request] 3 flow_out ?? runtime value 4..9 bdaddr[6] nap[0,1]:uap[2]:lap[3,4,5] bluetooth address of pairing device the host send s a cmd_pincode in response to this event. this event receives if accept pairi ng while in connectable mode enables via s register 15. 4.4.4 simple pairing this event inform s the host that a simple pairing procedure is in progress and the action byte in offset 10 tells the host what to do . event packet offset field value comments
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 100 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 event packet offset field value comments 0 length 15 1 channel 0 2 event [evt_ simple_pairing] 3 flow_out ?? runtime value 4..9 bdaddr[6] nap[0,1]:uap[2]:lap[3,4,5] bluetooth address of pairing device 10 action 0..3 see description below 11..14 actionval 4 bytes see description below the hos t react s to this event based on the value of the action byte in offset 10 as follows: action :: 0 this informs the host that a simple pairing procedure has been completed and actionval is 00000001 for success and 00000000 for fail. the host shall not react to this event with the cnf_simple_pairing packet. action :: 1 this informs the host that a simple pairing procedure is in progress and it will only display the passcode in actionval as a six d igit decimal number with leading zeroes. the host shall not react to this event with the cnf_simple_pairing packet. action :: 2 this informs the host that a simple pairing procedure is in progress and i t display s the passcode in actionval as a 6 d igit d ecimal number with leading zero s. the host react s to this event with the cnf_simple_pairing packet with a 00000000 value for no and a non - 00000000 value for yes. the former value, if the host deems that the passco de is not acceptable, and the latter if acceptable. action :: 3 this informs the host that a simple pairing procedure is in progress and the module is expecting a passcode from the host embedded in a cnf_simple_pairing packet. the host shall react to this event with the cnf_simple_pairing packet with a passcode value. the passcode in the cnf_simple_pairing is either obtained by reading the display on the peer device, or if the peer device is also a keyboard only, then the same random 6 digit value (with lea ding 0s) that is entered at both ends. 4.4.5 local friendly name this event send s a fragment of the local friendly name to the host. the maximum length of the fragment is 10, so at least 3 of these events are required to convey a loca l friendly name, if it has the maximum length of 30. event packet offset field value comments 0 length 16 1 channel 0 2 event [evt_lcl_fname] 3 flow_out ?? runtime value 4 index 0..29 start index into the string 5 len 1..10 number of valid characters in the name[] field that follows 6..15 name[10] xx xx xx xx the name fragment
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 101 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 4.4.6 remote friendly name this event send s a fragment of the remote friendly name to the host. the maximum length of the fragment is 10, so at least 25 of these events are required to convey a remote friendly name, if it has the maximum length of 248. event packet offset field value comments 0 length 16 1 channel 0 2 event [evt_rem_fname] 3 flow_out ?? runtime value 4 index 0..247 start index into the string 5 len 1..10 number of valid characters in the name[] field that follows 6..15 name[10] xx xx xx xx the name fragment 4.4.7 event_adc this event returns after a cmd_g et_io command where the analogid is set to either 1 or 2 . in thes e circumstances the module digitise s the voltage on either analogue 0 or analogue 1 and report s the va lue as an eight bit hex number . therefore the value shown in the valmsb field should always be zero . event packet offset field value comments 0 length 16 1 channel 0 2 event [evt_adc] 3 flow_out ?? runtime value 4 analogid 1..2 1 C C
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 102 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 5 hdp p rofile r elated e vents 5.1 associated this event inform s the host that an agent has associated with the manager and contains the handle, data specialization nominal code, device config id (as per the ieee standard) and a unique 8 byte identification number for the agent (or manager). it is relevant for both agent and manager roles. event packet offset field value comments 0 length 11 1 channel 0 2 event [evt_hdp_associated] 3 flow_out ?? runtime value 4 role 00=agent, 01==manager 5..6 handle[2] [5]=msb, [6]=lsb handle of the agent 7..8 spectype[2] [7]=msb, [8]=lsb data specialization nominal code. e.g 4111 (0x100f) for weigh scale 9..10 devcfgid[2] [9]=msb, [10]=lsb the negotiated config id. will be defined in the appropriate ieee data specialization standard. 11..18 sysid[8] 8 bytes this is a system id which is unique to the agent instant. 5.2 deassociated this event inform s the host that an agent has disassociated from the manager and contains the handle of the agent . it is relevant for both agent and manager roles. event packet offset field value comments 0 length 7 1 channel 0 2 event [evt_hdp_disassociated] 3 flow_out ?? runtime value 4 role 00=agent, 01==manager 5..6 handle[2] [5]=msb, [6]=lsb handle of the agent
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 103 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 5.3 time update this event generates for an agent role only and inform s the host that the agent received an updated date and time from the manager. event packet offset field value comments 0 length 11 1 channel 0 2 event [evt_hdp_timeupdate] 3 flow_out ?? runtime value 4 role 00=agent, 01==manager 5..6 handle[2] [5]=msb, [6]=lsb handle of the agent 11..14 datetime[8] ccyymmddhhssnnxx see note 1 the date/time information is supplied in this command as a string of 8 bytes ccyymmddhhssnnxx where each byte is as follows: cc century e.g for 2011 the value shall be 0x14 yy year e.g for 2011 the value shall be 0x0b mm month e.g for january the value shall be 0x01 and for say december 0x0c dd day e.g for 31 the value shall be 0x1f (0 is illegal value) hh hour e.g for 6:45pm the value shall be 0x1 2 nn minutes e.g for 6:45pm the value shall be 0x2d xx fraction this is a fraction of a seconds in hundred ths of unit. valid 00..0x63 (99 for example the date and time 2 feb 2011, 16:43:33.78 shall be sent at the string 150c020c102d214e 6 d ebug e vents 6.1 debug packet this event convey s debugging information to the host, and is available in engineering/beta builds only. event packet offset field value comments 0 length 16 1 channel 0 2 event [evt_debug_packet] 3 flow_out ?? runtime value 4 type_flag xx bit 0: first packet bit 1: last packet bit 2..5: reserved bit 6..7: message type 5..15 data[] contains ascii data string conveying message
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 104 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 6.2 malloc statistics this event convey s pool malloc statistics to the host and is available in engineering/beta builds only. event packet offset field value comments 0 length 16 1 channel 0 2 event [evt_debug_packet] 3 flow_out ?? runtime value 4..5 elsize[2] 0..n pool element size 6..7 numels[2] 0..n number of elements 8..9 taken[2] 0..n number of elements taken 10..11 maxtkn[2] 0..n tide mark for taken 12..13 ovflo[2] 0..n number of allocations from next bigger element because this size is maxed out
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 105 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 7 d ata c hannels this section provides details of some data channels which require further explanation. 7.1 hdp data channels 7.1.1 host to module direction channels b0 and b 1 upload attribu te data which then transfers to the appropriate data specialization data variable on receipt of a cmd_hdp_attrubute_write command. the host ensure s that the correct number of bytes for that attribute accumulat e in the channel , as length is the only val idation performed on the data; t he module does not interpret the data in any way besides length. with regards to the endienness of the data, this shall be determined by trial and error using an appropriate certified hdp manager. it is entirely possible that an at tribute can be defined which contains data requiring more than 253 bytes. a data packet cannot contain data more than 253 bytes s o this could present a problem. the solution to that is both channels b0 and b1 write into a buffer in the module to allow the host to accumulate attribute data using several da ta packets. however when using b0 it always first deletes any data al ready accumulated in the buffer and then writes to that buffer, whereas writing to channel b1 shall always append the data to the buffer. 7.1.2 module to host direction channels b0 and b1 send logical hdp packets to the host. channel b0 is always the first fragment of the logical pac ket and subsequent fragments send in channel b1. this means that when the host rec eives a packet on channel b0, it delete s all data accumulated for an existing ongoing logical packet. 7.2 logical packet format the format of the hdp logical packet is as follows: len packet_type data 2 bytes 1 byte n bytes len is set to n+3 and big endian, so th at the first byte of len sent on the wire is the msb . the data field structure depends on the logical packet type specified by packet_type and the following subsections describe the types of packets available at the time of writing. 7.2.1 packet type: attribute value this logical packet is s ent to the host as a result of processing the cmd_hdp_attribute_read command in either the agent or manager roles. for this logical packe t type the packe t_type field set s to 0x00 and the data field c onsists of 4 fields as follows: agent handle attr nominal code attr qualifier field attr value 2 bytes 2 bytes 2 bytes n bytes
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 106 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 t he agent handle, attr nominal code and attr qualifier id fields are all 2 byte fields in big endian format ( msb first) and echo from the cmd_hdp_attribute_read command , and attr value is the actual value of the attribute. calculate t he length of n by subtracting 9 from the len field of the logical packet. 7.2.2 packet type: scan report this logical packet sends to the host in a manager role as a result of scan report arriving from an agent. for this logical packet type the packet_ type field set s to 0x01 and the data field consists of multiple fiel ds as follows: agent handle person id num of objects data lists 2 bytes 2 bytes 1 byte n bytes t he agent handle and personid fields are 2 byte fields in big endian format ( msb first) , num of objects is a one byte field which specifies the number of objects , and the field data lists consists of multiple composit e fields structured as follows: field type data 1 byte n bytes field type can be 0x00 for object handle and 0x01 for attribute tag/value , and the size of the data field depends on the field type. the available field types/data are descri bed in the following sections. 7.2.3 field type: object handle this is the format of the object handle field type and is always 3 bytes long: 00 object handle always 0x00 2 bytes 7.2.4 field type: attribute tag/value this is the format of the attribute tag/value field type which is of variable size: 01 attr code attr value len attr value always 0x01 2 bytes 2 bytes n bytes the size of this field is attr value len + 5 7.2.4.1 example: scan report a sample logical sca n report packet is as follows: 0021 01 72b4 1234 01 00 0001 01 0a56 0004 12345678 01 0990 0008 2112021216453378 which is interpreted and expanded as follows -
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 107 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 scan report handle=29364 personid=4660, reports=1 o:1 (0001) a:2646 (0a56), 12345678 a:2448 (0990), 2112021216453378 7.2.5 sample code to interpret a scanreport logical packet the following code shows how a logical scan report packet could be separa ted into its constituent parts: void printscanreport( unsigned char *prxpkt, unsigned nrxpktlen) { char bamsg[512]; uint16 nhandle; uint16 npersonid; uint16 nobject; uint16 nattrid; uint16 nattrlen; uint8 *psrc; char *pmsg; nhandle = (prxpkt[3]<<8)+prxpkt[4]; npersonid = (prxpkt[5]<<8)+prxpkt[6]; printf(bamsg, "scan report handle=%d personid=%d, reports=%d" , nhandle, npersonid, prxpkt[7]); psrc = &prxpkt[8]; while (psrc < &prxpkt[nrxpktlen]) { switch (*psrc) { case hdp_scanreport_infotype_object: /* 0x00 */ psrc++; if ( psrc >= &prxpkt[nrxpktlen] ) { printf( "insufficient length -- abort display of msg" ); break ; } nobject = (psrc[0]<<8)+psrc[1]; printf( " o:%d (%04x)" ,nobject,nobject); psrc+=2; break ; case hdp_scanreport_infotype_attribute: /* 0x01 */ pmsg = bamsg; psrc++; nattrid = (psrc[0]<<8)+psrc[1]; psrc+=2; nattrlen = (psrc[0]<<8)+psrc[1]; psrc+=2; if ( &psrc[nattrlen] > &prxpkt[nrxpktlen] ) { printf( "insufficient length -- abort display of msg" ); break ; } pmsg += sprintf(pmsg, " a:%d (%04x), " ,
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 108 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 nattrid, nattrid, nattrlen); { uint16 nblocklen = (nattrlen>24) ? 24 : nattrlen; uint8 *pdata = psrc; while (nblocklen -- ) { pmsg += sprintf(pmsg, "%02x" ,*pdata++); } if ( nattrlen > 24 ) { pmsg += sprintf(pmsg, "..." ); } } psrc += nattrlen; printf(bamsg); break ; default : printf( "object type tag unknown %d -- abort display of msg" ,*psrc); return ; } }
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 109 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 8 m ultipoint a pplication e xamples 8.1 blob manager blob stands for binary long object. there are many bluetooth related operations w hich require lar ge strings to be submi t ted to the underlying bluetooth sta ck. for example, friendly names and extended inquiry responses fall into this category . these strings can be larger than the data packets allowed by the multipoint protocol defined in this specification. the blob manager is basically a software entity in the module which enables these large objects to be uploaded into the module in small packets and have them accumulated in a single object. the blob manager can be compile d time configured to manage up to n objects and unless special fi rmware builds are generated, this manual assumes that n is 2. each blob is given a zero based identifier. blobid 0 is the first object etc. a command packet called cmd_blobmanage exists to manage these blobs as required. this command takes four parameters: ? parameter 1 C t he subcommand id which tells the blob man ager what to do. ? parameter 2 C t he blob id ? o arameters 3 and 4 C 4 byte integer values used as arguments for the subcommand specified in parameter 1. the response packet also contains four parameters in exactly the same fashio n. where parameters 1 and 2 echo from the command and parameters 3 and 4 depend on the subcommand. recall that this entity manages blobs and cmd_blobmanage is the command to act on them. to get data into the blobs requires the use of data packets with specific dedicated channel numbers. channel numbers 0x98 hex to 0x9f hex are reserved for use with blobs 0 to 7 respectively. if data is sent in a data packet with a channel number cor responding to a blob that does not exist, then the data is silently discarded. data packets sent to the same blob append to any existing data in that blob . please be warned that sending data to a blob reduces memory for other uses , so laird highly recommen ds that the blob be cleared or used up as quickly as possible. the bluetooth chipset has very limited ram . once data accumulates in a blob , cmd_blobmanage perform s various actions on that blob which is specified via parameter 1 described as subcommand id above. some of the act ions possible are: ? clear C e mpties the blob identified by the blobid parameter 2 . ? ge tsize C r eturns the size of the blob in bytes in parameter 3 of the response . ? copyread C s ends a copy of all the data in the blob back over the uart in data channel (blobid+0x98) . ? hidset C m oves the data to the nonvolatile memory location , which stores custom hid descriptors. many hid descriptors can store and each is identified by a zero indexed identifier . i n this case , the hid id is specified in parameter 3 of the command ? hidget C a ppends the content of hid descriptor in nonvol atile storage identified by the hid id in parameter 1 into the blob identified by parameter 2. see description of the command cmd_blob_manage for all the ac tions possible.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 110 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 8.2 hid connections hid (human interface device) was originally described in detail in a specification published by the usb organization. the bluet ooth sig has built on that idea but uses wireless instead of usb as the t ransport mechanism. the hid specifications are very dry and heavy tomes from a developer s perspective , denying the user experience , which is it just works and is simple. the objective of the hid functionality provided in the laird bluetooth module is to provide the same it just works and is simple concept, but for developers. with this in mind, laird encourages that the developer view s the modules hid functionality as a black box and the only concepts to be aware and fully understand are input rep orts, output reports , and how to create a hid descriptor. the terminology for input/output is hid host centric where input means information flow from the hid device to the hid host , and vice versa output means information flow from hid host to hid dev ice. usb developers are familiar with this concept. input and o utput are packets of information whose format and size are predefined in the hid descriptor that totally describes the devices functionality. for example, the standard pc keyboard is defined by a hid descriptor which specifies that when a key is pressed or unpressed , an 8 byte input packet shall be sent to the host and likewise, if the host wants to update one of the leds on the keyboard (for example the numlock led ) then it shall send a 1 byre output packet. how the bits in the in put and output packets are interpreted are specified in the hid descriptor. in a nutshell, when something happens at the device end, it informs the host via an input packet, which is also called hid input report and l ikewise the host sends information at any time using output packets which are also called hid output reports. this implies that a developer using hid supplied in the laird module only needs to ask, what is the curr ent active hid descriptor and then fro m there decide how to generate and process th e reports. a simple interface suppl ied at the uart of the module enable s appropriate m apping of data into and out of input and output reports. the same interface also enables the developer to upload custom hid d escriptors into the non - volatile memory of the module. if no hid descriptor is uploaded, and the module is configured to expose a hid device profile, then by default a hid descriptor for a 104 key keyboard is exposed , meaning input reports are 8 bytes long and output reports are 1 byte long. in this case , when the host conveys a key press , an 8 b yte data packet has to submit to the module via the uart with data channel id 0xa0. likewise any output packets sent by the ho st appear on data channel 0xa0. if a h id host profile is act ive, then the input packets appear o n data channel 0x90 and it send output reports as data on channel 0x90. t he built - in h id device keyboard descriptor has been made even simpler to use if all you want is to send ascii characters in t he range 0x00 to 0x7f inclusive. in that case , all you must do is send the ascii string in a data packet on channel 0x20. the data parser in the module generate s two input reports for each ascii charac ter. the first input report specifies a key press and t he second input report specifies the unpress event. note: if s reg 3 specifies only hid profile , and s reg 39 specifies the built in keyboard hid descriptor, then the device class for the device in s reg 128 automatically overrides.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 111 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 8.3 sending input reports once a connection establishes , a report sends by a device end by sending an entire input report in a single data packet with channel id 0xa0. for example, if the descriptor specifies a standard keyboard and if the a key pr essed , then the following data sends o ver the uart to the module: 0a a0 00 00 04 00 00 00 00 00 and to convey that the left shift was pressed, t he data is: 0a a0 02 00 04 00 00 00 00 00 8.4 getting ouput reports from a host once a connection establishes, a report sends by a host to the device by sending an entire ouput report in a single data packet with channel id 0x90, for example : 03 90 01 8.5 uploading a hid descriptor into the module uploading of hid descriptors, which can be large blocks of arbitrary binary data, is done using the blob manager. the blob manager is an entity in the module which allows for blocks of binary data to be receive d over the uart and accu mulate in blob objects, of which two are made available. the two blobs of data have identifiers 0 and 1 respectively. in addition, data channels 0x98 to 0x9f are dedicated to data transfer to/from those blobs . where channel 0x98 is for blob 0, 0x99 is for blob 1. there is also a command called cmd_blobmanage which perform s various actions on the blobs . see the definition of that comm and for more details; suffice to say that there are subcommands for clearing, getting size, saving to non - vo la tile storage , and getting from non - vo latile storage. in the case of uploading a hid descriptor, the blob commands to use are clear and save. for example, if the contrived thirteen byte hid descriptor 05 01 09 06 a1 01 05 07 29 65 81 00 c0 is uploaded u sing blob 1 into non - vo latile location 1, (where this non - vo latile location reference is used in s register 39) then the following packets submit to the module on the uart. 0e 00 2d 7f 00 01 00000000 00000000 //cmd_blobmanage --- clear blob 1 0d 99 05 01 09 06 a1 01 05 07 29 65 81 //send data into blob 1 04 99 00 c0 //send more data into blob 1 which is appended to any existing data 0e 00 2d 7f 03 01 00000001 00000000 // cmd_blobmanage --- save blob 1 into nonvol storage id 1 8.6 specifying a custom hid descriptor for use after a custom hid descriptor uploads into the module where a hid descriptor in the range 0..n has b een sp e cified, the module can configure to use that descriptor when hid device profile is active by modifying s register 39. basically, take the 0 based hid id, add 1 to it and store that value in that register. 8.6.1 specifying service record name for custom hid for a custom hid descriptor, the device can also register a custom service name if it is saved using the blob manager. at any time , the default service name " bthidcustom can be invoked by deleting the service name from non - vola tile memory . this can be done by writing an empty name via the blob manager.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 112 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 8.6.2 hdp usage message the module offers both hdp agent and hdp manager roles with ieee data specialization functionality. hdp manager functionality is provided mainly for prototyping and testing an agent implementation and is not intended for eventual continua alliance certific ation. given two modules in factory default state, the following sections illustrate a typical usage session which consists of a pairing, an association, scan report, time update f rom manager , and disassociation. 8.6.3 message sequence chart host host module cmd_store_sreg cmd_store_sreg cmd_reset cmd_reset module in factory default mode module in factory default mode enable hdp+spp profile enable agent or manager role save sreg to nonvol memory reset to make sreg effective cmd_write_sreg [46 00000000] cmd_write_sreg [03 00000005] cmd_write_sreg [46 00000001] cmd_write_sreg [03 00000005] pair the devices cmd_pair_initiate [ addr ] evt_simple_pairing [ 00000001] evt_simple_pairing [ 00000001] evt_link_key [ addr ] evt_link_key [ addr ] rsp_pair_initiate [ok] agent manager module cmd_hdp_endpoint [100f 7363616c6500..] cmd_hdp_sdpregister register and activate hdp weigh scale sink role at manager cmd_bind [addr 100f] cmd_hdp_endpoint [100f 7363616c6500..] register and activate hdp weigh scale source roles at agent, and also bind agent to manager bluetooth address cmd_hdp_sdpregister rsp_bind [hhhh] associate cmd_associate [hhhh] evt_associated [h1h1 100f 05dc s...s] evt_associated [h2h2 100f 05dc s...s] continued on next page associated associated
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 113 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 host host module module agent manager associated associated send a fixed scan report cmd_hdp_scanreport_fixed [h1h1 pppp] blob 0 channel 98 [0a56 0990 0996] send a var scan report consisting of 3 attribute 0a56, 0990, 0996 cmd_hdp_scanreport_var [h1h1 pppp] send a time update from manager to agent cmd_hdp_set_time [h2h2 tttttttt] evt_hdp_timeupdate [h1h1 tttttttt] hdp data channel b0 [12345678] cmd_hdp_attribute_write [h1h1 0a56 0000] cmd_hdp_attribute_read [h1h1 0a56 0000] hdp data channel b0 logical packet type 01 [llll 01 h2h2 pppp [attr data]] hdp data channel b0 logical packet type 01 [llll 01 h2h2 pppp [attr data]] hdp data channel b0 logical packet type 00 [llll 00 h2h2 attr qqqq dddd] read attr from agent mds attribute 0a56 (2436 dec) (can be done only when associated) write a value into an agent attribute 0a56 (2646 dec) (can also be done when not associated) read agent attribute 0a56 (2646 dec) (can also be done when not associated) cmd_hdp_attribute_read [h2h2 0984 0000] hdp data channel b0 logical packet type 00 [llll 00 h2h2 attr qqqq dddd] cmd_disassociate [hhhh] evt_disassociated [h1h1] evt_disassociated [h2h2] disassociate disassociated disassociated
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 114 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 8.7 agent uart traffic for chart this section shows the uart traffic for a module operating as a hdp weigh scale agent communicating with a manager . i t is not a log of the uart traffic for the message sequence chart illustrated in the previous section. ********************************************** ********************************************** <70 006.896 08 00 81 7f 00 00 00 0c evt_status //state: reset_getaddr >70 000.000 04 00 02 7f cmd_read_bdaddr <70 000.078 0b 00 02 7f 00 0016a4fef000 rsp_read_bdaddr (mpstatus_ok) >70 000.015 05 00 17 7f 00 cmd_information //state: reset_getver <70 000.078 0e 00 17 7f 00 00 8100001300790673 rsp_information (mpstatus_ok) <70 001.810 08 00 81 7f 00 01 01 0c evt_status >70 057.018 09 00 04 7f 03 00000005 cmd_write_sreg <70 000.109 0a 00 04 7f 00 03 00000005 rsp_write_sreg (mpstatus_ok) >70 046.192 09 00 04 7f 46 00000000 cmd_write_sreg <70 000.109 0a 00 04 7f 00 46 00000000 rsp_write_sreg (mpstatus_ok) >70 004.790 04 00 05 7f cmd_store_sreg <70 000.109 05 00 05 7f 00 rsp_store_sreg (mpstatus_ok) >70 024.523 07 00 29 7f 000000 cmd_reset <70 001.918 08 00 81 7f 00 01 01 0c evt_status >70 775.201 1c 00 10 7f 10 0016a4fef001 3132333400000000000000000000000000 cmd _pair_initiate <70 007.300 0f 00 95 7f 0016a4fef001 00 00000001 evt_simple_pairing <70 000.156 0b 00 89 7f 0016a4fef001 00 evt_link_key <70 001.014 05 00 10 7f 00 rsp_pair_initiate (mpstatus_ok) >70 032.246 16 00 2e 7 f 100f 7363616c650000000000000000000000 cmd_hdp_endpoint <70 000.109 05 00 2e 7f 00 rsp_hdp_endpoint (mpstatus_ok) >70 009.298 0e 00 32 7f 0016a4fef001 100f 0000 cmd_hdp_bind <70 000.125 07 00 32 7f 00 b538 rsp_hdp_bind (mpstatus_ok)
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 115 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 >70 026.037 04 00 2f 7f cmd_hdp_sdpregister <70 000.125 05 00 2f 7f 00 rsp_hdp_sdpregister (mpstatus_ok) >70 011.918 06 00 31 7f b538 cmd_hdp_associate <70 000.109 05 00 31 7f 00 rsp_hdp_associate (mpstatus_ok) <70 002.013 08 00 81 7f 00 00 01 0c evt_status <70 003.775 13 00 97 7f 00 b538 100f 05dc 4c414952444d4752 evt_hdp_associated >70 029.235 06 b0 12345678 >70 018.127 0b 00 36 7f b538 0a5 6 0000 cd cmd_hdp_attribute_write <70 000.109 08 00 36 7f 00 cd 0004 rsp_hdp_attribute_write (mpstatus_ok) >70 013.697 0b 00 35 7f b538 0a56 0000 ab cmd_hdp_attribute_read <70 000.109 0f b0 000d00b5380a56000012345678 //hdp channel : attribute for handle=46392 attr=2646 qualifierid=0} value = 12345678 <70 000.016 08 00 35 7f 00 ab 0004 rsp_hdp_attribute_read (mpstatus_ok) >70 042.900 09 00 33 7f b538 1234 ab cmd_hdp_scanreport_fixed < 70 000.421 08 00 33 7f 00 b538 ab rsp_hdp_scanreport_fixed (mpstatus_ok) >70 021.185 08 b0 0a5609900996 >70 014.571 0a 00 34 7f b538 1234 cd 00 cmd_hdp_scanreport_var <70 000.109 08 00 34 7f 8f b538 cd rsp_hdp_scanre port_var (mpstatus_attrlist_invalid) >70 035.365 0a 98 34 7f 0a56 0990 09 96 cmd_hdp_scanreport_var >70 008.752 0a 00 34 7f 0a56 0990 09 96 cmd_hdp_scanreport_var <70 000.125 08 00 34 7f 8b 0a56 09 rsp_hdp_scanreport _var (mpstatus_invalid_blobid) >70 019.906 08 98 0a5609900996 >70 012.823 0a 00 34 7f b538 1234 cd 00 cmd_hdp_scanreport_var <70 000.296 08 00 34 7f 00 b538 cd rsp_hdp_scanreport_var (mpstatus_ok) <70 043.166 0e 00 98 7f b538 1 40b020c102d214e evt_hdp_timeupdate >70 008.486 06 00 30 7f b538 cmd_hdp_disassociate <70 000.125 05 00 30 7f 00 rsp_hdp_disassociate (mpstatus_ok) <70 000.125 07 00 96 7f 00 b538 evt_hdp_disassociated
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 116 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 8.8 manager uart traffic for chart this section shows the uart traffic for a module operating as a hdp manager communicating with a weigh scale agent. ********************************************** *********************************** *********** ********************************************** <71 003.900 08 00 81 7f 00 00 00 0c evt_status //state: reset_getaddr >71 000.000 04 00 02 7f cmd_read_bdaddr <71 000.094 0b 00 02 7f 00 0016a4fef001 rsp_read_bdaddr (mpstatus_ok) >71 000.015 05 00 17 7f 00 cmd_information //state: reset_getver <71 000.078 0e 00 17 7f 00 00 8100001300790673 rsp_information (mpstatus_ok) <71 001.810 08 00 81 7f 00 01 01 0c evt_status >71 062.806 09 00 04 7f 03 00000005 cmd_write_sreg <71 000.109 0a 00 04 7f 00 03 00000005 rsp_write_sreg (mpstatus_ok) >71 022.449 09 00 04 7f 46 00000001 cmd_write_sreg <71 000.109 0a 00 04 7f 00 46 00000001 rsp_write_sreg (mpstatus_ok) >71 016.209 04 00 05 7f cmd_store_sreg <71 000.109 05 00 05 7f 00 rsp_store_sreg (mpstatus_ok) >71 011.310 07 00 29 7f 000000 cmd_reset < 71 000.717 08 00 81 7f 00 00 00 0c evt_status <71 001.950 08 00 81 7f 00 01 01 0c evt_status <71 787.103 0f 00 95 7f 0016a4fef000 00 00000001 evt_simple_pairing <71 000.188 0b 00 89 7f 0016a4fef000 00 evt _link_key >71 018.564 16 00 2e 7f 100f 7363616c650000000000000000000000 cmd_hdp_endpoint <71 000.125 05 00 2e 7f 00 rsp_hdp_endpoint (mpstatus_ok) >71 005.413 04 00 2f 7f cmd_hdp_sdpregister <71 000.125 05 00 2f 7f 00 rsp_hdp_sdpregister (mpstatus_ok) <71 067.751 08 00 81 7f 00 00 01 0c evt_status <71 002.028 13 00 97 7f 01 72b4 100f 05dc 0016a4fef000b539 evt_hdp_associated >71 093.210 0b 00 35 7f 72b4 0984 0000 ab cmd _hdp_attribute_read <71 000.110 15 b0 00130072b40984000000080016a4fef000b539 //hdp channel : attribute for handle=29364 attr=2436 qualifierid=0} value = 00080016a4fef000b539 <71 000.000 08 00 35 7f 00 ab 000a rsp_hdp_attribute_read (mpstatus_ok) <71 011.419 23 b0 00210172b4123401000001010a5600047856341201099000080000000000000000 //hdp channel : scan report handle=29364 personid=4660, reports=1 // o:1 (0001) // a:2646 (0a56), 78563412 // a:2448 (0990), 0000000000000000 <71 113.210 47 b0 00450172b4123401000001010a5600047856341201099000080000000000000000010996000206c 3010a5600047856341201099000080000000000000000010996000206c3 //hdp channel : scan report handle=29364 personid=4660, reports=1 // o:1 (0001) // a:2646 (0a56), 78563412 // a:2448 (0990), 0000000000000000 // a:2454 (0996), 06c3 // a:2646 (0a56), 78563412 // a:2448 (0990), 0000000000000000
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 117 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 // a:2454 (0996), 06c3 >71 043.056 0e 00 37 7f 72b4 140b020c102d214e cmd_hdp_set_time <71 000.109 05 00 37 7f 00 rsp_hdp_set_time (mpstatus_ok) <71 008.721 07 00 96 7f 01 72b4 evt_hdp_disassociated <71 002.059 08 00 81 7f 00 01 01 0c evt_status 8.8.1 sniff mode explained bluetooth connections are master/sl ave in nature. a master sends packets and a slave has to acknowledge that packet in the next timeslot. timeslots in bluetooth are 625 microseconds w ide. this implies that a master always know s when packets are sent and received, which further means it is a ble to optimize power usage by switching on power hungry circuitry only when needed. a slave , however, does not have prior knowledge of when a packet will be r eceived and has to assume that a packet will be r eceived from a master on every receive slot. th is means that it has to leave its receiving circuitry switched on for most of the receive slot duration. the result of this is high power consumption where a slave with no data transmission still consumes around 31 ma , whereas a master consumes only 6 ma. this problem was identified early in the evolution of bluetooth (especially since headsets spend all their time as a slave in a bluetooth connection) and it was solved by having a mode called sniff, with appropriate lower layer negotiating protocol. sniff mode during connection is an agreement between the slave and its master that null packets are only exchanged for n timeslots every m slots. the slave can then assume that it will never be contacted during n - m slots, and so can switch its power hungry circ uitry off. the specification goes further by also specifying a third parameter called timeout (t) which specifies extr a timeslots that the slave agree s to listen for, after receiving a valid data packet. put another way, if a data packet is received b y the slave then it knows that it must carry on listening for at least t more slots. if within that t slot tim e period another data packet receives, then the timer restarts . this mechanism ensures low power consumption when there is no data transfer C at t he expense of latency. w hen there is a lot of data to transfer , it acts as if s niff mode was not enabled. it is stated above that during sniff mode, a slave listens for n slots every m slots. the bluetooth specification states that a master can have up to 7 slaves attached to it with all slaves requesting varying sniff parameters. it may therefore be impossible to guarantee that each slave gets the m parameter it requested. in light of this, the protocol for enabling sniff mode specifies that a requesting peer specify the m parameter as a minimum and maximum value. this allow s the master to interleave the sniff modes for all slaves attached. for this reason, the sniff parameters are specified in the bluetooth module via four s registers. sregister 73 (561 in at mode) specifies n, sregister 74 (562 in at mode) specifies t , and sregist ers 75/76 (563/564 in at mode) specify minimum m and maximum m respectively. although the specification defines these parameters in terms of timeslots , the s register values have to be specified in units of milliseconds and the firmware does the necessary translation to timeslots. the relationship between m , n , t , and power consumption when sniff mode is activated is illustrated in figure 8 - 1 .
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 118 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 figure 8 - 1 : sniff mode 8.8.2 uart host power saving facility there are circumstances where a cpu driving the module consumes a lot of power and some me ans are necessary to reduce that power consumption while the module is in a bluetooth connection. to facilitate that, the module has many gpio pins , and using s registers 50 to 65, on e (and only one) gpio pin can configure with the value 13 so that it is an output configuration. the state of the pin is 0 when the modules uart transmit buffer is empty and 1 when there is at least one byte waiting to b e transmitted to the uart host. hence a workable power saving strategy by the cpu is illustrated in figure 8 - 2 .
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 119 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 figure 8 - 2 : cpu power saving strategy 8.8.3 out of band (oob) pairing when two device s pair using the legacy procedure or the simple secure pairing method, the end result is that they both end up with the same 16 byte random key . this key is subsequently used to authenticate and encrypt subsequent connections. this means the list of pairing kept in each device as a minimum, needs to store the peer bluetooth address along with the 16 byte link key. the bluetooth specifications do not mandate that this link key shall only generate/exchange over the bluetooth radio, and in fact mention out - of - band (oob) pairing as a valid means of expediting the pairing of two devices. the specification does not describe how the oob pairing occurs. is pin high? assert rts wait for data to arrive from module deassert rts configure to wake up when pin goes high go to sleep pin goes high wake up and assert rts
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 120 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 whatever oob means are chosen, it implies that some externally generated key has to be added to the trusted devic e database in the device. the module caters for this link key addition using the cmd_trusted_db_add command when in the multipoint protocol mode and the at+ky command when in the at protocol mode. 8.8.4 throughput analysis the follow ing are factors that affect overall data throughput: ? baudrate C the baudrate at the uart determines the maximum throughput and has a theoretical maximum of 80% of the baudrate i f using none parity and one stop bits . that theoretical maximum red uces to aro und 67% if parity is enabled along with two stopbits. ? radio utilization C the radio utilization in the sense that at any time, up to three non - transient operations could be active. the radio could be servicing on - going connections, it could be scanning for inquiries , and it could be scanning for incoming connections. for the latter two, the scanning operation has a duty cycle and the worst case of 100% has a major impact on the throughput as the radio is time shared between the connections and the scanning operations . ? rf connection quality C if the quality is bad and there are many retries of packets, then the throughput can drop to close to zero before the connection automatically drops . for basic rate connection packets , the best throughput limits to around 600 kbps in asymmetric data transfer falling to around 400 kbps for symmetric transfers when using base rate rf packets . this can triple when using edr packets . ? rfcomm frame size C the size of the rfcomm frame, which according to the bt spec can be a value between 23 and 32767. the bigger the value the better, but the incremental gain around 1000 and above is negligible for embedded bluetooth stack with limited ram. this value set s v ia s register 11 in multipoint mode and 9011 in at mode ? mp packet payload size C in the mult ipoint protocol which is packet - based, the size of the mp packet payload has an impact and in fact the packets should be as large as possible, and yet the mp protoc ol limits the maximum payload to 253 bytes due to the length field of the packet being only a single byte. the charts that follow, where actual throughput is plotted against the rfcomm frame size, show that in multipoint mode the packet structure and scann ing for inquiries and paging have a significant impact on the throughput. with regards to mp mode, the uart host should optimize performance by sending data to transmit in as large packets as possible and completely disabling all scanning operations by set ting s registers 4 and 5 to zero . it is entirely possible for the host to bombard the module with the worst case scenario of three byte packet s with just one data byte payload . in this case , if too many of these packets are sent and the framesize is large ( such as 64 and above) , it is entirely possible for the module to lose the connection by resetting. this happens because the module panics when it runs out of memory . on the rare occasion th at this happens, it is possible to mitigate this issue by increasing the value of s register 81. by default this value is set to 30%. testing by laird shows that with a framesize larger than 64 and sending a storm of three byte packets (with one byte paylo ad) and the default value of 30%, it is possible to panic the module into a reset. testing with a value of 50% in s reg 81 solves the problem. but increasing the value of s register 81 has an impact on how many simultaneous spp connections can be sustained . basically, users must fine tune s registers 7,8,9,10,11,81 and mp packet sizes to ensure desired throughput operation.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 121 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 -50000 50000 150000 250000 350000 10 210 410 610 810 1010 1210 1410 simplex throughput (bps) rfcomm framesize (sreg 11 {ats9011}) at mode througput (bps) -50000 150000 350000 0 200 400 600 800 1000 1200 1400 1600 simplex throughput (bps) rfcomm framesize (sreg 11) multipoint mode througput (bps) - conn'ble & disc'ble pkt len 1 pkt len 10 pkt len 25 -150000 350000 0 200 400 600 800 1000 1200 1400 1600 simplex throughput (bps) rfcomm framesize (sreg 11) multipoint mode througput (bps) - not conn'ble & disc'ble pkt len 1 pkt len 10 pkt len 25
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 122 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 8.8.5 uart protocol selection & indication via gpio s register 255 select s either mp(1) or at(2) protocol mode for communications over the uart. if s register 255 is set to zero , then it implies that a gpio select s the protocol such that zero set s at mode and one for mp mode. to configure a particular gpio pin for this functionality, set the appropriate s reg (in range 50 to 65) to a value of 14. only the first s register in the range 50 to 65 is used, any further s registers with the value 14 are ignored. i n addition, if at le ast one s register in the range 50 to 65 is set to a value of 15, then on power u p that pin configures as an output and set s to zero if at protocol is active and one if mp is active. if s register 255 is zero and no gpio is configured for this funct ionalit y, then the protocol default s to mp. 8.8.6 firmware upgrade via uart the module has the capability of upgrading the firmware via the uart port using a windows pc based utility supplied by laird. f irmware upgrades over the air a re not planned as this is not inherently supported by the chipset vendor. the upgrade process requires a direct connection to rx, tx, cts , and rts lines of the module via appropriate rs232 level conversion, to a built - in serial port on the windows pc. the new firmware deploys in a .dfu file as and when new firmware is available. if the user requires the ability to upgrade the firmware when their product is in the field, then provision must be made so that the rx, tx, cts , and rts lines are exposed to the o utside world. this is complicated if, as in most usage cases, a host microcontroller drives the bt module i n the users end product. in that case, the host microcontroller drive the modules rx and cts input lines and hence cannot also be driven by a wind ows pc unless those two lines are gated appropriately. one solution is incorporating the hardware logic illustrated below and use a usb to serial adapter as per http://www.ftdichip.co m/products/cables/usbttlserial.htm which does not require rs232 levels. note: t his solution should work in theory and laird does not warrant that it will work given it has not been implemented and tested. the purpose of the suggestion is to make the user evaluate the convenience arising from it and variations thereof.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 123 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 8.8.7 the hcommand & event values the following is a lis ting of a snapshot of the file bmhostprotocol.h at the time of this documents release . laird does not guarantee that this listing is kept up to date. for development purposes, please request the latest version of the appropriate c header file. //++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++ //the following are command (octet 2) values in command/response packets //++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++ #define cmd_no_opera tion 0x01 #define cmd_read_bdaddr 0x02 #define cmd_read_sreg 0x03 #define cmd_write_sreg 0x04 . . . . . . . . . . . . //++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ +++++++ //the following are event (octet 2) values in event packets
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 124 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 //++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++ #define evt_status 0x81 #define evt_ invalid_ pktsize 0x82 #define evt_unknown_command 0x83 #define evt_inquiry_result 0x84 #define evt_modem_status 0x85 . . . . . . . . . . . . 8.8.7.1 status values the following is a list ing of a snapshot of the file mpstatus.h at the time of this documents release . laird does not guarantee that this listing will be kept up to date. for development purposes, please request the latest version of the appropriate c header file. #define mpstatus_ok 0x00 #define mpstatus_illega l_command 0x01 #define mpstatus_no_connection 0x02 #define mpstatus_hardware_fail 0x03 #define mpstatus_page_timeo ut 0x04 . . . . . . . . . . . . 9 at a pplication e xamples 9.1 connection management commands atd, ata, ath, at+btp, and at+btg are all connection related and are discussed generically in this section. on con nection, depending on the value of s register 531, the module enter s data pass through m ode (s reg 531 = 0) or remain s in command mode (s reg 531 > 0). in pass through mode , any data received from the host passes to the transmit buffer of the rf connection ; in the case of spp ( uuid =1101) and for all other profiles, it depend s on whether a canned mode is provided. data coming from the remote sends out to the host transparently C even in canned mode. a canned mode, which exists for hid profile, is where t he inc oming character from the host translates into appropriate multi - byte packets expected by the pee r . for example, with hid standard keyboard profile where each key press results in an 8 byte hid input report to the host, the ascii character appropriate ly expands into the relevant 8 bytes denoting tha t the key was pressed and then imme diately another 8 byte report denote s that the same key was unpressed. if a canned mode is not available for a profile, then module is not allowed to get into pass - through mode. in command and online mode , the command atxdata force s the module to send data and conversely any incoming data presents to the host in an rxdata asynchronous response.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 125 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 9.1.1 incoming connections the module can be configure d using the at+btp or at+btg command so that it scan s for incoming connections from other bluetooth devices. it can also be configured via s register 512 to be in this mode by default on power up. when the lower layers detect an incoming call, a ring 12345 6789012 string sends to the host every se cond. the command ata accept s the connection and ath reject s it. on connection, if the s0 register is >=0 and s504=0 then confirmat ion to the host is in the following form: connect ,,< where is the uuid of the profile that accepted the connection. 9.1.2 dropping connections in a convent ional telephony modem, a call normally terminates by first sending a +++ escape sequence enveloped by an escape sequence guard time (of the order of 100 to 1000 milliseconds) to enter local command + connected mode , and then the ath command to force a disconnection. the laird modules provide a couple of ways of dropping a connection. one method is similar to the above, but instead uses a ^^^ character sequence . this eliminates ambiguity when a data call is in progr ess via a mobile phone which established using the mobile phones bluetooth at modem. the se cond method involv es the host deasserting the dtr modem control line (dsr modem status line from the modules viewpoint) for longer than 500 milliseconds. the escape sequence to force the module from pass - through mode and into command is as follows: w here is 100 milliseconds. the four guard time s means that even when a file transfer is occurring and it happens to be full of characters , it is not going to drop into command mode . this is because when transferring a file , it happen s as fast as possible and so the inter character gap will be significantly shorter than the . the character can be changed via the s2 register. 9.2 profiles this section describes all the profiles that the module is capable of making and accepting connection when in at mode. 9.3 serial port profile (spp) uuid : 1101 you must set s register 9003 bit 0 to make this profile act ive. outgoing connections are initiated using the command: atd k incoming connections result in at least one ring response to the host. if s register 0 is a non - zero value then after the appropriate number of ring responses the connect ion automatically accepts and a connect ,1101,< k?qdronmrd?rdmcr to the host. if s register 0 is 0, then the incoming connection accepts by the host using the command ata or rejected using ath. on connection, depending on the value of s register 5 31, the module enter s p ass - through mode (data transparently exchanged between uart and air - side) or in command+onli ne mode. in the latter, data is s endt
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 126 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 to the peer using the atx comman d and any data from the peer either dumps silently (s531=1) o r send to the host in an rx asynchronous response (s531>1). when in pass - through mode, th e escape sequence ^^^ put s the module into command and online mo de so that a disconnection can initiate. a disconnection can also initiate by deasserting the dsr input line of the module for more than 500 milliseconds. on disconnection a no carrier async response sends to the host. 9.4 hid device profile (hid) uuid : 1124 s register 9003 bit 1 must be set to ma ke this profile active. in addition , s register 9039 must be set to 0 and above to enable a device hid profile and a negative value to enable a host hid profile. outgoing connections initiate using the command: atd,1124 k incoming connections are automatically accepted and a connect ,1124,< k?rdmcr to the host. with the hid profile, a built - in standard keyboard hid descriptor is supplied along with a canned mode of operation. it enables a legacy device generating ascii characters to present to a host as a compliant hid keyboard. in canned mode , each ascii character ( ascii characters 128 and above are silently discarded) results in two input reports to the host. the first is a corresponding key press and the second is a corresponding k ey unpress. when the host sends the 1 byte output report sends to the host as - is. in non - canned mode (s reg 531 > 0) the host has to send the raw 8 byte input reports in the atx command and conversely any output reports from the host send to the ho st in rx< string> asynchronous responses. disconnections from t he module initiate via dsr deassertion. h owever , if the module is in non - canned mode (s register 531 > 0) then it is also possible to initiate a disconnection using the ath command. on disconnec tion a no carrier async response is s ent to the host. 9.4.1 hid descriptors hid s present their capabilities to a host in a hid descriptor which is essentially a block of octets that describe the devices capability and more importantly how events convey back and forth. this concept was originally developed by the usb organisation and has been adopted by the bluetooth sig virtually intact. the hid descriptor contains information about input and ou tput reports. they are both blocks of octe ts described to contain various bit fields descr ibing the event that needs conveyed to the peer. hence, at the end of the day, if a hid implementation w as viewed as a communications black box between a device and host, then it could be viewed as the device generating an input repor t consisting of x bytes which presents to the host and conversely an output report consisting of y bytes sends by the host to the device. in this modules hid implementation, the module does not care about the content of those inp ut and output reports. an input report presents to the module by the uart host in a n atx which the n de - escapes and sends as a single atomic packet to the remote host. similarly , each output package arrives atomically in a single pack et from the remote host which then sends to the uart host in a single rx message. it was mentioned above that by default a standard keyboard hid descriptor is built into the firmware and the default value of s register 9039 makes the module connectable via a h id device profile.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 127 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 it is possible to download up to two cust om hid device descriptors to store in the modules non - volatile memory. these custom hid device descriptors are then identified via a number in the ran ge 0 to n. if s register 9039 changes to a va lue 1 to n+1, then on power up, if s reg 9003 indicates that hid profile is to be made available, it implement s the appropriate custom hid descriptor in the service discovery database. when custom hid descriptors are downloaded and stored , there is no vali dation performed on the block of data. this is because the module has no context to perform such validation. in mp mode, to download a custom hid descriptor, you can use the utility mpbthost.exe. right click on the window to invoke a pop - up menu and select upload hid descriptor. i n the new dialog box , enter the blob id (recommend leave at 0) and hid id to use. then to use that descriptor update s register 9039 with a value which is hidid+1. 9.5 hdp profile (health device profile) uuid : 1400 ,1401,1402 9.5.1 background health device profile (hdp) is available on the module in both agent and manager roles as defined by the continua alliance (see www.continua.org ). th ere are two aspects to hdp: one is the transport lay er, for which only bluetooth is catered for by this module (although the continua alliance has also ratified others, for example usb), and the other aspect is ieee data encapsulation. the laird module pr ovides a tightly coupled integrated solution for a weigh scale specialization agent. more specializations will be p rovided in the future as and when there is demand via a firmware update. it is assumed that the reader is familiar with all the hdp and ieee documentation and relevant guidelines published by the continua alliance. for hdp , it is assumed that the reader has access to the specification from the bluetooth sig . f or ieee it is assumed that the reader has access to the ieee11073 - 20601 optimised exch ange protocol specification and the device specializations specifications 11073 - 10401 through to 10499. for the weigher scale specialization embedded in the module , the specification is 11073 - 10415. obtain t he ieee standards from their website standards.ieee.org , and bluetoot h hdp specification s at www.bluetooth.org . the ieee data specialization along with the bluetooth physical transport defined in the appropriate specifications is very dry and difficult to understand , and it is pointl ess to reproduce that information here verbatim. however, an attempt is made to describe it from the modules usage point of view where the module and the functiona lity it provides is treated in a black box manner. 9.5.2 ieee black box model in a traditional health related environment, typical actors and props are the patient, instruments that measure appropriate parameters, health professionals , and the (manual and/o r automatic) archiving of the records. over the years there have been many suppliers of the instruments that measure appropriate param eters who have all provided proprietary methods for getting the data stored in records. it has always been the role of the health professionals to transcribe the data from the vario us instruments into the archive records. the manual process presents risks associated with errors in the transcribing p rocess and so manufacturers provided even more proprietary solutions to automating that task. the continua alliance came about to address that confused picture with guidelines and a certification process to ensure that a consistent inter - operable picture emerges with regards to the instruments that measure appropriate parameters and the method for gett ing the data stored in records.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 128 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 the last thing the continua alliance would want to do is dictate how any individual instrument (referred to as an agent) is physically designed , as that is best left to the engineers who know how best to design them. instead , they have specified abstract data models for the various types of instruments, which they refer to as data specializations, and how they shall convey the data to an entity called a manager that can be used to consistently store the data in an archive. examples of data specializa tion abs tract models exist for weigh scales, thermometers, glucose meters, blood p ressure meters, ecgs , and many more will become available as they progress through various stages in appropriate working groups. any continua alliance member is free to recommend cre ation of data specializations as needed. once ratified, the end result is always an abstract data model which defines what data is pertinent for that instrument and how it shall be presented to the real world. 9.5.3 abstract data model from a software engineers perspective, an abstract data model for an ieee data specialization can best be described as a collection of arrays of different types of data (which the specifications refer to as attributes). each attribute is unambiguously defined to consist of a tag, a type , and the actual value. there is no reliance on any programmi ng language in the definition; i t is purely a data model. as a minimum there shall be one array of attributes called the medical device system, henceforth ref erred to as an mds which represents the properties and services of the device, independent of its health data capabilities and its status . t here shall also be one array of attributes called the numeric, henceforth referred to as nu which contains episodic measurements. there is also an rt - sa collection which to represent s continuous samples or waveforms. other collections exist and the reader is advised to refer to the ieee11073 - 20601 stand ard for a definitive list, described under the general heading of domain information model. at this point, imagine an hdp agent as just a collection of data records that can be read and written to locally under program control and each data point i s identified by its tag and publ ish es its data type. this is analogous to a database table with 4 fields in each record. three fields are called tag, type , value , and the fourth field is called collection name such as mds or nu or rt - sa. you should further imagine this database as accessible from a manager over a physical transport media such as bluetooth or us b. the procedure a manager use s to gain access to that database of attributes is rigidly defined and standardised via a service model using an association state machine defined in the ieee11073 - 20601 standard. this service model is encapsulated in the laird module and the user is encouraged to think of it in terms of a black box whose internal details are not relevant. the picture that should emerge for the laird modul e user who requires a data specialization is that of a black box consisting of that conceptual database with a 4 field table and an engine that implements the association service model over bluetooth so that it facilitates the mirroring of that said data base at the hdp manager end. this picture then vastly simplifies the design and development of a health instrument that is required to be continua alliance certified. the hope is that, the user is only required to have a general idea about the content of t he ieee 11073 - 20601 and the data specialization ieee11073 - 104xx standards. the following subsections provide more details as to how you can control and manipulate the black box. please note that initially only a weigh scale data specialization as defined i n 11073 - 10415 is available embedded inside the black box. by embedded it is implied that the mds and nu collections are pre - defined as per the standard and the attributes that may change values are exposed to the user for manipulation. in future it is ho ped that a generic api will be exposed that allow s any data specialization to be do wnloaded and tested. i f a user requires a specific data specialization then they are encouraged to contact laird with that request until that generic api is made available .
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 129 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 it is also pertinent to note that once a user has a working instrument using this module, the user must obtain bluetooth listing (quoting the qdid of the laird module) prior to continua alliance testing and certification. 9.5.4 hdp agent model from a software perspective the hdp agent implementation is as shown in the diagram below. figure 9 - 1 : hdp agent implementation the diagram shows that the a gent model is the bluetooth communications stack . the stack consists of an sdp record that exposes to the outside world the data specializations it is capable of, a laird ieee/hdp service encapsulation layer which relay s commands and responses to the host , and 0 or m ore instances of data specializations. at the time of the first firmware release , only a weigh scale specialization is offered. 104xx data specialisation - b 104xx data specialisation - c 104xx data specialisation - weigh scale (4111) attributes nu collection attributes mds collection attributes attributes nu collection other collections attributes mds collection attributes attributes nu collection other collections attributes mds collection bluetooth stack uart responses/events commands ieee/hdp 'black box' agent model bluetooth hdp profile laird ieee/hdp services encapsulation 4111,scale 4104,thermometer xxx,something sdp record
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 130 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 all uart commands available to the host are provided so that the various entities in the black box can be controlled or interro gated. given there can be many agent specializations embedded in the firmware, they are identified in various commands using a 16 bit handle. 9.5.5 weigh scale data specialization the weigh scale specialization (nominal co de 4111) is embedded in the firmware is shown as below and it contains a mds and an nu object. figure 9 - 2 : embedded weigh scale specialization the mds object is defined in the firmware with the following attributes: attribute tag data type comments mdc_attr_id_handle 2337 handle always: 0 mdc_attr_sys_type_spec_list 2650 type_spec_list const mdc_attr_id_model 2344 system_model var:systemmodel mdc_attr_sys_id 2436 octet_string var:systemid mdc_attr_dev_config_id 2628 config_id 1500 (0x05dc) mdc_attr_attribute_val_map 2645 attr_val_map const mdc_attr_id_prod_specn 2349 prod_spec const mdc_attr_time_abs 2439 absolute_time var:time mdc_attr_mds_time_info 2629 mds_time_info const mdc_attr_power_stat 2389 power_status var:powerstatus mdc_attr_val_batt_charge 2460 intu_16 var: batt, chrg. mdc_attr_time_batt_remain 2440 batmeasure var:time_batt_remain the nu object is defined with the following attributes : attribute tag data type comments mdc_attr_id_handle 2337 handle always: 1 mdc_attr_id_type 2351 type const mdc_attr_metric_spec_small 2630 metric_spec_small const mdc_attr_unit_code 2454 oid_type var:weight units mdc_attr_attribute_val_map 2645 attr_val_map 2646,2448 mdc_attr_time_stamp_abs 2448 absolute_time var:time mdc_attr_nu_val_obs_simp 2646 simple_nu_obs_val var:weight mdc_attr_nu_accur_msmt 2378 float_type always: 1 mdc_attr_msmt_stat 2375 measurement_status var:meas. stat. the attribu tes commented as variables expose to the host for reading and writing via the uart interface using at+hag and at+has commands respectively and are described in detail elsewhere in this document. 104xx data specialisation - weigh scale (4111) attributes nu collection attributes mds collection
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 131 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 the uart interface identifies t he variable attributes mentioned above using an attribute id and an additional sub id. the concept of sub id is a laird artefact and is not part of any ieee stan dard, but the attribute id is the same as those defined in the ieee standard in most cases . the complete list for the weigh scale speciali zation is as per the table below and should be used with the agent attribute read/write commands at+hag and at+has. note : t he attribute values passed back and forth from the host are not validated in any way by the firmware in the laird module. it is up t o the host to ensure that the correct data writes into an attri bute. any illegal values are picked up at time of continua alliance certification testing which prevent s certification. table 9 - 1 : variable attrib utes in weigh scale specialization attribute name (see ieee spec for format) attr id sub id size in bytes weight 2646 0 4 weight units 2454 0 2 time 2448 0 8 power status 2389 0 2 battery charge 2460 0 2 time battery remain C C C C 9.5.6 thermometer data specialization the thermometer s pecialization (nominal code 4104 ) is embedded in the firmware is shown as below and it contains a mds and an nu object. figure 9 - 3 : embedded thermometer specialization the mds object is defined in the firmware with the following attributes: attribute tag data type comments mdc_attr_id_handle 2337 handle always: 0 mdc_attr_sys_type_spec_list 2650 type_spec_list const 104xx data specialisation - thermometer (4104) attributes nu collection attributes mds collection
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 132 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 mdc_attr_id_model 2344 system_model var:systemmodel mdc_attr_sys_id 2436 octet_string var:systemid mdc_attr_dev_config_id 2628 config_id 800 (0x0320) mdc_attr_id_prod_specn 2349 prod_spec const mdc_attr_time_abs 2439 absolute_time var:time mdc_attr_mds_time_info 2629 mds_time_info const mdc_attr_power_stat 2389 power_status var:powerstatus mdc_attr_val_batt_charge 2460 intu_16 var: batt, chrg. mdc_attr_time_batt_remain 2440 bat_measure var:time_batt_remain the nu object is defined with the following attributes : attribute tag data type comments mdc_attr_id_handle 2337 handle always: 1 mdc_attr_id_type 2351 type const mdc_attr_metric_spec_small 2630 metric_spec_small const mdc_attr_unit_code 2454 oid_type var:weight units mdc_attr_time_pd_msmt_active 2649 relative_time var:time (int32) mdc_attr_attribute_val_map 2645 attr_val_map 2646,2448 mdc_attr_time_stamp_abs 2448 absolute_time var:time mdc_attr_nu_val_obs_basic 2636 basic_nu_obs_val var:temperature mdc_attr_nu_accur_msmt 2378 float_type always: 1 mdc_attr_msmt_stat 2375 measurement_status var:meas. stat. the attribut es commented as variables expose to the host for reading and writing via the uart interface using at+hag and at+has commands respectively and are described in detail elsewhere in this document. the host id entifies t he variable attributes mentioned above on the uart interface using an attribute id and an additional sub id. the concept of sub id is a laird artefact and is not part of any ieee standard, but the attribute id is the same as those defined in th e ieee standard in most cases . the complete list for the thermometer specialization is as per the table below and should be used with the agent attribute read/write commands at+hag and at+has. note : t he attribute values passed back and forth from the host are not validated in any way by the firmware in the laird module. it is up to the host to ensure that the correct data writes into an attribute. any illegal values are picked up at time of continua alliance certification testing which prevent s certification. table 9 - 2 : variable attributes in thermometer specialization attribute name (see ieee spec for format) attr id sub id size in bytes temperature 2636 0 2 temperature units 2454 0 2 absolute time 2448 0 8
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 133 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 power status 2389 0 2 battery charge 2460 0 2 time battery remain C value 2440 0 4 time battery remain C unit 2440 1 2 measurement status 2375 0 2 system id 2436 0 8 system model C product name 2344 0 12 system model C model name 2344 1 16 serial number 2349 0 8 measurement active period 2649 0 4 9.5.7 glucometer data specialization the glucometer s pecialization (nominal code 4113 ) embedded in the firmware is shown as below and it contains a mds and an nu object. figure 9 - 4 : embedded glucometer specialization the mds object is defined in the firmware with the follow ing attributes: attribute tag data type comments mdc_attr_id_handle 2337 handle always: 0 mdc_attr_sys_type_spec_list 2650 type_spec_list const mdc_attr_id_model 2344 system_model var:systemmodel mdc_attr_sys_id 2436 octet_string var:systemid mdc_attr_dev_config_id 2628 config_id 1700 (0x06a4) mdc_attr_id_prod_specn 2349 prod_spec const mdc_attr_time_abs 2439 absolute_time var:time mdc_attr_mds_time_info 2629 mds_time_info const mdc_attr_power_stat 2389 power_status var:powerstatus mdc_attr_val_batt_charge 2460 intu_16 var: batt, chrg. mdc_attr_time_batt_remain 2440 bat_measure var:time_batt_remain the nu object is defined with the following attributes : attribute tag data type comments mdc_attr_id_handle 2337 handle always: 1 mdc_attr_id_type 2351 type const 104xx data specialisation - glucometer (4113) attributes nu collection attributes mds collection
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 134 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 attribute tag data type comments mdc_attr_metric_spec_small 2630 metric_spec_small const mdc_attr_unit_code 2454 oid_type var:weight units mdc_attr_attribute_val_map 2645 attr_val_map 2646,2448 mdc_attr_time_stamp_abs 2448 absolute_time var:time mdc_attr_nu_val_obs_basic 2636 basic_nu_obs_val var:temperature mdc_attr_nu_accur_msmt 2378 float_type always: 1 mdc_attr_msmt_stat 2375 measurement_status var:meas. stat. the attribut es commented as variables expose to the host for reading and writing via the uart interface using at+hag and at+has commands respectively and are described in detail elsewhere in this document. the host identifies the variable attributes mentioned above on the uart interface using an att ribute id and an additional sub id. the concept of sub id is a laird artefact and is not part of any ieee standard, but the attribute id is the same as those defined in the ieee standard in most cases . t he complete list for the glucometer specialization is as per the table below and should be used with the agent attribute read/write commands at+hag and at+has. note : t he attribute values passed back and forth from the host are not validated in any way by the firmware in the laird module. it is up to the h ost to ensure that the correct data is written into an attribute. any illegal values are picked up at time of continua alliance certification testing which prevent s certification. table 9 - 3 : variable attributes in glucometer specialization attribute name (see ieee spec for format) attr id sub i d size in bytes blood glucose 2636 0 2 blood glucose units 2454 0 2 absolute time 2448 0 8 power status 2389 0 2 battery charge 2460 0 2 time battery remain C C C C
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 135 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 9.6 agent related at commands this section describes all the commands used to manage the agent role for hdp. 9.6.1 connection to an hdp manager command: at+haahhhh response: ok or error nn or had:assoc iate xxxx ok or had:disassociate xxxxerror nn description: this command establish es a connection to an hdp manager and associate s the agent with it so that attribute data can be exchange d . the bluetooth address of the hd p manager and the agent specialization that needs to associate is defined by the handle hhhh , which is pre - obtained using command at+hab. thi s command wait s for the procedure to complete successfully or otherwise before responding with ok or error. if th e agent is already associated then an immediate ok is the response. if the agent is not already associated then a bluetooth connection initiates and as soon as a connection establishes , th e association state machine progress es through to negotiating a conf iguration and then ultimate ly confirms the association. if association is successful , then a hda:associate .. asynchronous response sends to the host . i f association fails (because bt connection failed or configuration could not be negotiated) then the async resp onse hda:disasociate sends to the host. an ok or error response terminates the procedure. note : i f s reg 9071 is non - zero, then there is an automatic disassociation after a time specifie d by that register. the timer restarts every time a sca n report sends to the manager. sreg required settings : bit 2 set in s9003 and s9070=0 9.6.2 bind a data specialization command: at+hab,iiii response: hhhh ok or error nn description: this command bind s a data specialization identified by the nominal code iiii (for example 4111 = weigh scale) with a n hdp manager identified by the bluetooth address . for this command to be successful, the data specialization identified by i iii has to be pre - embedded in the firmw are. although the firmware allow s multiple bindings to the same specialization, please be aware that it is th e same object and each instance does not have a
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 136 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 unique set of attributes. if the binding is successful, the n a 16 bit handle hhhh (a decimal number) returns, which is then used as a parameter in many subsequent commands. sreg required settings : bit 2 set in s9003 and s9070=0 9.6.3 disassociate an agent command: at+hadhhhh response: ok < cr,lf> or > had:disassociate xxxxok or error nn description: this command disassociate s an agen t identified by the handle hhhh from a manager. this command wait s for the procedure to complete successfully or otherwise before responding with ok or error. if the agent is already disassociated then an immediate ok is the response. sreg required settings: bit 2 set in s9003 and s9070=0 command: at+haeiiii,name response: ok or error nn description: this command must be issued prior to sending the at+hal commands and include s the data specialization endpoint iiii with the string name as a n hdp source (agent ) in the sdp record that is ex posed to potential peers. this tells potential peers that the device offers a iiii data specialization source. without this entry in the sdp record, a manager is not able to make a connection to the hdp agent, although it is rare for a manager to initiate connections in typical usage scenarios. sreg required settings : bit 2 set in s9003 and s9070=0 command: at+haghhhh,aaaa,ssss response: hhhhhhhhhhhhhh ok or error nn < cr,lf> description: this command read s (g et s ) the value of one of the variable attributes identified by aaaa and sub id ssss in the attribute collections for that agent identified by the handle hhhh. for the embedded weigh scale data specialization this command read s the value of an attribute listed in table 9 - 1 . the value always returns as a string of hexadecimal digits representing the binary value, and the size of that string is even. different attributes have different sizes. sreg required settings: bit 2 set in s9003 and s9070=0 command: at+hal
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 137 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 response: ok or error nn description: this command must issue after sending at least one at+hae command, and register s and activates the sdp record with information supplied in the at+hae commands. without the sdp record, a manager is not able to make a connection to the hdp agent, although it is rare for a manager to initiate connections in typical usage scenarios. sreg required settings: bit 2 set in s9003 and s9070=0 command: at+harhhhh,pppp[,aaaa[,aaaa[]]] response: ok or < cr,lf> error nn description: this command trigger s a scan r eport for person id pppp (16 bit decimal number) from the agent identified by handle hhhh. if the agent is not associated with the bou nd manager (see at+hab) then it first trigger s the start of an association. once association exists, a scan report sends . if [,aaaa[,aaaa[]]] is absent from the co mmand, then the standard scan report as identified by the attribute mdc_attr_attribute_val_map in the nu collection sends to the manager. othe rwise, the [,aaaa[,aaaa[]]] can be a list of any attribute mentioned in the nu collection. for example, to send a scan report with just the measurement status, just specify the single value 2375. please note that only attributes mentioned in the nu collec tion are allowed. any aaaa value not found in the nu collection is silently ignored. sreg required settings: bit 2 set in s9003 and s9070=0 command: at+hashhhh,aaaa,ssss,hhhhhhhhhhhh response: ok or error nn description: this command write s ( s et s )a new value hhhhhhhhhhhh to one of the variable attributes (identified by aaaa and sub id ssss) in the attribute collections for the agent identified by the handle hhhh. for the embedded weigh scale data specialization , this command write s to an attribute listed in table 9 - 1 . the value hhhhhhhhh is in hexadecimal and is not validated in any way apart from the requirement that it shall be twice the size in bytes as specified for that attribute. sreg required set tings: bit 2 set in s9003 and s9070=0 9.6.4 agent related at asynchronous responses this section describes all the asynchronous responses sent to the host by the hdp agent. each response is framed by a at the start and end. command: no co mmand. this is a status message. response: hda:disassociated hhhh
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 138 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 description: this response sends the host when an association attempt fails (as a result of at+haa or at+har co mmands) or when an association terminates by either at+had or due to loss of bluetooth connectivity. the parameter hhhh which is a 16 bit decimal number identifies the agent. command: no command. this is a status message. response: hda:associated hhhh,iiii,cccc,sssssssssssss description: thi s response is s ent to the host when a successful association happens for the agent identified by hhhh (16 bit decimal number). for completeness, the data specialization nominal code iiii (16 bit decimal) and the device configuration id cccc (16 bit d ecimal), that got negotiated with the manager, is also provided. the 16 character parameter ssssssss specifies the system id of the manager. note: an agent data specialization can be basic as specified in the relevant spec, or one of the more enhanced o nes which have more capabilities. for example, with the weigh scale, laird provides for the basic mds collection, but it is possible to specify multiple mds collection s which expose more functionality (e.g. body mass index attributes). these extended colle ctions are identified by configuration ids and are offered to a manager during the association phase in descending order of complexity until the manager accepts one that it can work with. command: no command. this is a status message. response: hda:time hhhh,ccyymmddhhmmssaa description: this response sends to the host when a manager sends new time information by writing to the mdc_attr_time_abs attribute in the mds collection of the agent identified by hhhh. the time ccyymmddhhmmssaa is a 16 character hexadecimal val ue which is encoded as follows: cc cent ury (e.g. 14==20) yy year (e.g. 0b==11) mm month (e.g. 0c==12) dd day (e.g 1f==31) hh hour (e.g. 17==23) mm minutes (e.g 32==50) ss seconds (e.g. 2f==47) aa hundreths of seconds (e.g 63==99) for example, the data and time 12 feb 2011, 16:45:33.78 sends as 140b020c102d214e 9.6.5 hdp manager model from a software perspective the hdp manager implementation is as shown in the diagram below and the functionality is provided mainly to enable prototyping and regression testing of agent special izations. there are many far more capable hdp managers available which are hosted on a pc. for example, the latest toshiba bluetooth stack is hdp capable and there are imminent bluez releases for linux pcs.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 139 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 figure 9 - 5 : manager model with bluetooth communications stack figure 9 - 5 shows that the manager model consists of the bluetooth communications stack . the stack consists of : ? a n sdp record that exposes to the outside world the data specializations it may accept as s inks ? a laird ieee/hdp serv ice encapsulation layer which relay s commands and responses to the host ? 0 or more instances of specialization associations. associated agent object associated agent object associated agent object associated agent object associated agent object bluetooth stack uart responses/events commands laird ieee/hdp services encapsulation 4111,scale 4104,thermometer xxx,something sdp record ieee/hdp 'black box' manager model partial list of mds attrs partial list of nu attributes attributes attributes partial list of mds attrs partial list of nu attributes attributes attributes partial list of mds attrs partial list of nu attributes attributes attributes partial list of mds attrs partial list of nu attributes attributes attributes partial list of mds attrs partial list of nu attributes attributes attributes bluetooth hdp profile
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 140 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 these associated agent objects are transient and come into existence only when an agent successfully associates. the associated process results in the top few attributes in the mds and nu collections caching in the manager whic h the host reads using the at+hmg command after an association. just like the agent en d, the manager indicate s via it s sdp record which data specializations it is capable of sinking, and commands analogous to the ones provided for the agent model have been provided to manipulate that sdp record content. 9.7 manager related at commands this section desc ribes all t he commands used to manage the a gent role for hdp. command: at+hmeiiii,name the data specialization endpoint iiii with the string name as a hdp peers that the device offers a iiii data specialization sink. identified by hhhh. the parameter oooo collection cache and 1 for the nu collection cache and aaaa is the description: this command must issue after sending at least one at+hme command and register s and activate the sdp record with information supplied in the at+hme commands. without the sdp record, an agent is not able to make a connection to the hdp manager. sreg required settings : bit 2 set in s9003 and s9070=1 command: at+hmthhhh, ccyymmddhhmmssaa
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 141 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 response: ok or error nn description: this command send s the current data and time to the associated agent identified by handle hhhh. the time ccyymmddhhmmssaa is a 16 character hexadecimal val ue which is encoded as follows: cc c entury (e.g. 14==20) yy year ( e.g. 0b==11) mm month (e.g. 0c==12) dd day (e.g 1f==31) hh hour (e.g. 17==23) mm minutes (e.g 32==50) ss seconds (e.g. 2f==47) aa hundreths of seconds (e.g 63==99) for example, the data and time 12 feb 2011, 16:45:33.78 sends as 140b020c102d214e sreg required settings: bit 2 set in s9003 and s9070=1 9.7.1 manager related at asynchronous responses this section describes all the asynchronous responses sent to the host by the hdp manager. each response is framed by a at the start and end. command: no command. this is a status message. response: hdm:disassociated hhhh description: this response sends to the host when an association terminates by an agent or due to loss of bluetooth connectivity. the parameter hhhh which is a 16 agent identified by hhhh (16 bit decimal number). for completeness, the data specialization nominal code iiii (16 bit decimal) and the device id cccc (16 bit decimal is also provided. the 16 character parameter ssssssss specifies the system
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 142 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 response: hdm:scanperiod hhhh description: this response sends to the host when a scan report receives from agent identified by handle hhhh. since a scan report can consist of data values for many attributes, this report is formatted with embedded characte rs as follows: < cr>hdm:scanreport hhhh:pppp o:oooo a:aaaa,ddd..ddd a:aaaa,ddd..ddd o:oooo a:aaaa,ddd..ddd a:aaaa,ddd..ddd where o: identifies the collection object (oooo == 1 for nu etc) and then subsequence a: lines consist of value pairs aaaa,ddd.ddd where aaaa is the attribute nominal code and ddd...ddd is its value in hexadecimal. the size of the value for each attribute is specified in the ieee sta ndards.
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 143 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 9.7.1.1 sample host/module message sequence in a typical weigh scale usage, the sequence of commands (red) and r esponses (blue) from the module is as follows, where it assumed that the both ends start of from f actory default state: ================================= agent ================================= ================================= manager ================================= ats9003=5 ok ats9070=1 ok at&w ok ats9003=5 ok ats9070=0 ok at&w ok ============================ pairing ============================ at+btw0016a4fef005 ok pair 0 0016a4fef005 pair 0 0016a4fef004 ============================ register sdp records ============================ at+hme4111,"scale" ok at+hml ok at+hae4111,"scale" ok at+hab0016a4fef005,4111 46392 ok at+hal ok ============================ associate ============================ at+haa46392 hda:associated 46392,4111,1500,4c414952444d4752 hdm:associated 29364,4111,1500,0016a4fef004b538 ok ============================ read attibutes @ manager ============================ at+hmg29364,0,2628 05dc ok ============================ read attibutes @ agent ============================
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 144 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 at+hag46392,2646,0 0000004b ok ============================ write attibutes @ agent ============================ at+has46392,2646,0,00000123 ok at+hag46392,2646,0 00000123 ok ============================ send time ============================ at+hmt29364,140b020c102d214e ok hda:time 46392,140b020c102d214e ============================ send fixed scan report ============================ at+har46392,1234 hdm:scanreport 29364:1234 o:1 a:2646,00000123 a:2448,2011021216453378 ok ============================ send variable scan report ============================ at+har46392,1234,2454,2448,2646,2375 hdm:scanreport 29364:1234 o:1 a:2454,06c3 a:2448,2011021216453378 a:2646,0000004b a:2375,8000 ok ============================ disassociate ============================ at+had46392 ok hda:disassociated 46392 hdm:disassociated 29364
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 145 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 9.7.2 authentication and encryption the module and firmware is bt v2.1 compliant so it uses simple secure pairing (ssp) to authenticate devices to trust , and only invoke s a legacy pairing procedure when a peer device is v2.0 or older. it is not possible to configure the unit to be only capable of legacy pairing and still have v2.1 approvals. the purpose of pairing, whether legacy or ssp, is to generate the same random 16 byte key at both ends . the key is then used in subsequent connections for authentication and encryption. 9.7.3 legacy pairing a legacy pairing procedure is automatically used when pairing is initiated (by either end) and the peer is approved to v2.0 and below. 9.7.3.1 outgoing to initiate a pairing, the host shall submit the command at +btw to which it get s an immediate ok or error response. the host then wait s for a pin ? response to which it respond s with the command at+btk=pincode. when the pairing procedure complete s, the module send s to the host the following asynchronous response : pair n . n is 0 when the pairing is successful, 1 for a timeout , and 2 for a generic failure (for example, mismatching pincode). 9.7.3.2 incoming the module has to be in at least connectable mode for it to participate in a pairing initiated from a legacy peer. th e first indicati on the host get s that an incoming legacy pairing has initiated is when it receives the asynchronous response pin ? . to this, the host respond s with a shared pincode conveyed in the command at+btk=pincode. whe n the pairing procedure complete s, the module send s to the host the following asynchronous response : pair n . n is 0 when the pairing is successful, 1 for a timeout , and 2 for a generic failure (for example, mismatching pincode). 9.7.4 simple secure pairing simple secure pairing was introduced in v2.1 of the bluetooth specification to simplify the pairing procedure so it did not rely on a pre - shared pincode and so that all connections are forced to be encrypted. unlike pre v2.1 devices, it is not possible to create connections without encryption. simple secure pairing uses the diffie - hellman public/private encryption methodology to expedite a common 128 bit key at both ends. this eliminates the need for pre - shared pincodes but introduces the man in the mid dle (mitm) attack vulnerability. to address the mitm vulnerability the concept of verification via a 6 digit passcode was also added. a 6 digit passcode was selected, as that reduces the probability of a random m itm attack succeeding to one in a million. the 6 digit passcode is not a pre shared code, but is a random 6 digit artefact derived from the diffie - hellman calculations such that knowledge of that 6 digit number by an attacker cannot result in back - calcula tion of the 128 bit key that generated. for a user to interact and process the 6 digit passcode the ssp procedure requires that each bluetooth device have an i/o capability which is one of the following : ? none
enhanced class 1 bluetooth v2.1 module firmware users guide embedded wireless solutions support center: http://ews - support.lairdtech.com www.lairdtech.com/bluetooth 146 americas: +1 - 800 - 492 - 2320 europe : +44 - 1628 - 858 - 940 hong kong: +852 2923 0610 ? display only ? d isplay with a yes/no button ? keybo ard only this i/o capability exchanges by t he two peers going through a pairing procedure so that the optimal user interaction selects at both ends. for example, if one end admits to keyboard only and the other to display only, then the two nego tiate that the display end shows the passcode with an appropriate prompt to get the user at the other end to type in the passcode. when either has none capabilit y, then pairing procedure c omplete s without any mitm protection by both ends automatically accepting the passcode generated by the pairing algorith m. 9.7.4.1 i/o capability the i/o capability of the module is set via s register 6 (9006 in at mode) where the value to set is as follows: ? 12 = no i/o capability ? 13 = display with yes/no ? 14 = keyboard only ? 15 = display only when both ends are keyboard only, you can enter a pre - shared 6 digit number . when both ends are display only it is unlikely the two devices have services that are of use to either and so it could be contrived combination. 9.7.4.2 outgoing to initiate a pairing, the host shall submit the command a t +btw to which it get s an immediate ok or error response. the host then shall wait for a passkey? n response to which it shall respond with the command at+btk=passcode or at+btky or at+btkn depending on the value of n in the pa sskey? message. when the pairing procedure complete s, the module send s to the host the following asynchronous response : pair n . n is 0 for a successful pairing , 1 for a timeout , and 2 for a generic failure (for example, mismatching pincode). a s you can see, the host is able to determine if ssp or legacy pairing is in progress because in the former the challenge message is passkey? whereas in the latter it is pin ? 9.7.4.3 incoming the module has to be in at least connectable mode for it to particip ate in a pairing initiated from a ssp capable peer. the first indication the host may get is t hat an incoming pairing has initiated is when it receives the asynchronous response passkey? n . to this, the host respond s with the command at+btk=pa sscode or at+btky or at+btkn depending on the value of n in the passkey? message. when the pairing procedure complete s , and for just works, the modul e send s to the host the following asynchronous response : pair n

▲Up To Search▲

Price & Availability of BT740-SC

	To Download BT740-SC Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .